Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Suppose I have some drive with a single partition. For some reason I decide to repartition it, using fdisk. I create multiple partitions, then write the partition table, then exit fdisk. At this point the kernel is still not aware of the new partition table : the initial partition is still mounted through NFS, it was only "lazy-unmounted" (umount -l) before fdisk, so it triggered the "device or resource busy" error.

Now I change my mind, launch fdisk again, and merge all partitions into a single one, exactly as it was at first. Then again I write the partition table, exit fdisk, and the kernel still has no clue of what just happened.

Finally, I rm -rf everything on the disk, then copy some new data on it.

Question is : what happens at the next reboot, when the kernel will see the "new" (yet same as before) partition table ? Will the data will be straight readable by the system ?

share|improve this question
up vote 5 down vote accepted

There are two places where the partition table is stored: on disk, and in RAM. It sounds like you updated the disk without updating the RAM, then changed the disk back. So if the kernel is still going on what's in RAM, and the next time you boot it reads the same thing off the disk, then yes, it should work.

However, you need to be really careful that your previous filesystem was actually unmounted. umount -l doesn't unmount anything. If it's still mounted, and you mount it again and start changing data, you're asking for trouble.

From this and other questions you've posted, it sounds like you're digging yourself a deeper and deeper hole by trying to do more and more things to this disk in an attempt to avoid things like rebooting or even just reconfiguring the NFS server. While it's possible all of these tricks will work out, any mistake anywhere can easily lead to severe data corruption. Make sure your backups are up to date.

share|improve this answer
Well, mistakes have already been made — several by me, the first one by the one who used a backup drive (mounted on /mirror…) to serve config files on a whole bunch of data taking nodes. Anyway I had already backed up the whole drive (including its less than 0.01 % of useful data) on another machine. But actually what is described here was not an attempt to correct anything, but my first actions. I've stopped after the rm -rf and am just wondering now if it's worth rsyncing the primary drive or not. – Skippy le Grand Gourou Nov 7 '12 at 22:36
Indeed I'm afraid I did remount the filesystem while it was not unmounted and wrote data on it… – Skippy le Grand Gourou Nov 7 '12 at 22:38

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.