2

Not sure if it's better suited for superuser of serverfault boards, let me know.

I have a drive which I repartitioned with fdisk. Initially there was only one big partition, now there are a number of partitions. Now the new partition table won't be taken into account by the kernel until the next reboot.

The point is that there are some data on this drive which are shared through NFS, and which should be present on the drive when rebooting. Also, I want to avoid modifying configuration files, even temporarily. So I would like to ensure these data are on the first partition, /dev/sdb1, corresponding to the previous single partition, so that they are immediately available at next boot.

So is there a (simple) way to write data on particular sectors or blocks on the drive ? Is it the purpose of the dd "seek" option ? If I manage to do that the data will still be readable at next reboot once the new partition has been taken into account, right ?

FWIW, the amount of data is not so large, 2.1 MB, but /dev/sdb1 is only 82 MB and the drive is 160 GB.

Thanks.

Edit : For the whole history and why I cannot reload the partition table (which would be the best solution), see this question on serverfault.

Edit2 : Ok, I may have found a workaround, which would be to copy files from elsewhere as soon as the machine is rebooted, before NFS is set up.

Edit3 : Nevermind Edit2, the new /dev/sdb1 wouldn't be formatted yet…

Edit4 : Actually, this last edit probably discards the whole question, as it applies in any case. Should have think of that earlier…

Improve this question
3
  • So you are willing to take a serious risk of on-disk data corruption (including the possibility of file system metadata corruption) in order to avoid modifying a few configuration files? Commented Nov 7, 2012 at 14:45
  • Sort of, though I was not expecting such a risk. Thing is that I know nothing about NFS, that I'm not the one who have setup the machine, and that modifying configuration files would impact the whole system which is one of the main key points of a large architecture, while the drive we're talking about is only a drive which was intended for backup, but finally not used until now except for these data (read-only configuration files shared by NFS clients) which I don't know who had the stupid idea to store on a backup drive. Commented Nov 7, 2012 at 15:04
  • BTW, I figured out the seek option of dd is not what I'm looking for. Commented Nov 7, 2012 at 15:05

2 Answers 2

Reset to default
2

You need to deal with NFS and get it to stop exporting the old drive. You can't just keep dismissing that with "this is not an option".

That said, if you want direct access to a particular block on a device without relying on kernel partitions, then yes, dd and its seek and skip options will work. If you want to access a range of sectors as a block device, you can use a loop device which you set up via losetup to have a particular offset and size limit. Finally, you could always boot a new kernel in a virtual machine (e.g. using libguestfs) with your /dev/sdb device attached, which would read and use the partitions as they're stored on the device.

Improve this answer
1
  • Thanks. Though I probably won't use it because of (and rather go for the NFS solution) it was what I was looking for. Concerning my comment on dd & seek, I probably misread this explanation, I guess using a device instead of a file should do the trick. Commented Nov 7, 2012 at 22:39
2

Why don't you instead look into techniques to induce the kernel to reread the partition table. For example, you could use partprobe, as described here.

Another option is the -R flag to sfdisk.

Another option is blockdev, as described here.

Improve this answer
5
  • Right, I should have mentioned I already tried partrobe without success. I had decided to wait for a reboot of the machine, but it probably doesn't harm to ask for a solution on how to force the reload of the partition table. I'll post a link later. Commented Nov 7, 2012 at 15:10
  • Just tried blockdev --rereadpt /dev/sdb and sfdisk -R /dev/sdb, same issue : BLKRRPART: Device or resource busy. This is because the partition is shared through NFS. Commented Nov 7, 2012 at 15:18
  • Can't you shut manually down nfs? Commented Nov 7, 2012 at 15:22
  • @dupiousjim : No, this is not an option. Commented Nov 7, 2012 at 15:49
  • I've posted the related question on serverfault. Commented Nov 7, 2012 at 15:50

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.