I have a SMP machine with a IDE hard disk running 2.5-bk20030611.
Today I changed the partition table of the disk, using fdisk, and
noticed, after reboot, that the new partition table was not written to
the disk. Before rebooting, 'fdisk -l /dev/hda' shows the new partition
table, as if it were written.
I've made a few more tests, and even if I sync() a dozen of times
before rebooting (using /bin/sync and sysrq), the data is not written.
Even when I've waited about 20 minutes after changing the partition table,
before rebooting, the problem persisted.
Although, after changing fdisk to call fsync() before closing the device,
everything worked, the changes were written, and the new partition table
were on the disk, after rebooting.
I think that changing fdisk to use fsync() would be a Good Thing, but
I guess that sync() should have the data be written, anyway.
Am I missing something?
If there is any additional information I could give, please let me know.
Regards,
--
Eduardo
Eduardo Pereira Habkost <[email protected]> wrote:
>
> Today I changed the partition table of the disk, using fdisk, and
> noticed, after reboot, that the new partition table was not written to
> the disk. Before rebooting, 'fdisk -l /dev/hda' shows the new partition
> table, as if it were written.
>
> I've made a few more tests, and even if I sync() a dozen of times
> before rebooting (using /bin/sync and sysrq), the data is not written.
> Even when I've waited about 20 minutes after changing the partition table,
> before rebooting, the problem persisted.
>
> Although, after changing fdisk to call fsync() before closing the device,
> everything worked, the changes were written, and the new partition table
> were on the disk, after rebooting.
argh, is this a plot?
It is some interaction between sync() and the presence of dirty data against
the ramdisk driver. You can work around it by not using the ramdisk driver,
by using `blockdev --flushbufs /dev/hdXX' or by using fsync, as you have
done.