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…

Community
  • 1
Skippy le Grand Gourou
  • 3,293
  • 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? – user Nov 07 '12 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. – Skippy le Grand Gourou Nov 07 '12 at 15:04
  • BTW, I figured out the seek option of dd is not what I'm looking for. – Skippy le Grand Gourou Nov 07 '12 at 15:05

2 Answers2

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.

dubiousjim
  • 2,698
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.

Jim Paris
  • 14,337
  • 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. – Skippy le Grand Gourou Nov 07 '12 at 22:39