Re: Moving partition to an overlapping position

[Szakacsits Szabolcs]

On Wed, 20 Jul 2005, K.G. wrote:
> On Wed, 20 Jul 2005 13:27:25 +0200 (MEST) Szakacsits Szabolcs 
> <address@hidden> wrote:
> > 
> > Did you md5's of all files before and after?
> Of course.

Great! :-)
 
> > 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 agree :-)
 
> I'm quite sure this possible for the kernel to tell the HD to flush his cache

It's possible but not all journalling fs do it, moreover the disk or the
disk controller can still ignore it.

> (or journaling wouldn't be so usefull)

Indeed. Journaling isn't so useful as people think.

> , 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 ;))

Over the last three years I've debugged a lot of ntfsresize related
problems. These were due to hardware, memory, IDE cable, kernel and all
short of partitioner problems.

Far the most damage was caused by [lib]parted (at least 6 digits),
incorrectly changing the geometry because it believed the kernel which has
changed HDIO_GETGEO ioctl semantics in 2002 (in early 2.5 kernels and
because nobody used it, nobody reported the problem and two years later
the argument was that "nobody complained in the last two years").

However I didn't find yet any problems with the north and south bridge
design :-))
 
> 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. 

Yes, in ext3 terms this is called 'ordered' mode. Ntfsresize works the
same but I removed every flushes, except the last one before exit(0),
because they completely killed performance, and anyway they also don't
guarantee anything.

Please note, that unless power goes down or the box crashes, flushes don't
matter for consistency but they matter a lot for how the kernel's I/O
scheduler can optimize reads and writes.

Cheers,
        Szaka