On Wed, 20 Jul 2005 13:27:25 +0200 (MEST) Szakacsits Szabolcs <[EMAIL PROTECTED]> wrote: > > On Wed, 20 Jul 2005, K.G. wrote: > > > > I've run a couple of tests, violently unplugging the computer while > > resizing > > a HFS, and at least it worked fine for me :) > > Did you md5's of all files before and after?
Of course. > Of course this is still the > "worked a couple of times for me on my hardware" category which isn't too > solid in general. I know it doesn't mean anything for the general case. But it's still better than if the power outage had destroy my whole fs... I'm quite sure this possible for the kernel to tell the HD to flush his cache (or journaling wouldn't be so usefull), and I think this is done during ped_geometry_sync operation. I'll investigate. If this is, then the probability to lose anything, at least during an HFS resize - I don't know the other fs implementation, is very low (I wouldn't say null, because I would have to prove my code, parted middleware code, the kernel code, the HD firmware code and the microprocessor, north and south bridge design... and i really don't want to do that ;)) I just copy one file at a time in a non overlapping way on some free space, then flush the cache, and right after that the file system is updated and the cache is flushed again. This is quite simple and I haven't be able to imagine anything safer. Even using the HFS+ journal if available wouldn't give a significant greater safety, because the only things that are to be keept in sync for each atomic move is the description of the physical location of the file and a bitmap of used blocks. The bitmap is repaired by any fs check such as one done by apple's disk utils. Cheers, Guillaume _______________________________________________ Bug-parted mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-parted
