Re: Moving partition to an overlapping position

[K.G.]

On Wed, 20 Jul 2005 13:27:25 +0200 (MEST) Szakacsits Szabolcs <address@hidden> 
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