bug-parted
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sanity check needed


From: Andrew Clausen
Subject: Re: sanity check needed
Date: Sat, 18 Aug 2001 10:28:44 +1000
User-agent: Mutt/1.2.5i

Hi Stuart,

On Fri, Aug 17, 2001 at 05:42:58PM -0400, Stuart D. Gathman wrote:
> Version 1.4.17
> 
> Wanted to reduce a FAT 32 partition from 28G to 12G.  Stupidly, I typed 
> 
> parted> resize 1 0.037 12.0
> 
> (I meant to type 12000.0, of course.)
> 
> Parted reported that it ran out of clusters - but only *after* trashing
> the partition.

Ouch!  That shouldn't happen (needless to say!)

> There should really be a sanity check here.

Obviously, there are.

> The free
> space on the FAT32 drive can be quickly determined and checked that it
> is bigger than the proposed reduction.

Right.

Anyway, when you typed "resize 1 0.037 12.0", a lot was going on.

First, it knows you can't resize to 12 meg.  It has a constraint
saying "this is the samllest legal size".  It didn't even ask you
if you want to convert to FAT16... so it certainly wasn't thinking
in the range of 12 meg.  (The minimum size of FAT32 is about 500Mb,
IIRC)

Of course, the fact that the constraint solver finds the "nearest"
solution to the command, and blindly follows it without warning you
is bad.  I have fixed this now.

Anyway, that's not the problem we're interested in.

The FAT code returned a constraint that it could not fulfill,
*AND* the FAT code didn't handle "oh shit, I ran out of clusters!"
gracefully (which it should).

I am investigating now.  I can reproduce "ran out of clusters",
but it did no damage to my file system.  Still trying...

BTW, I can see that the get_resize_constraint() function is broken...
Actually, it's going to be a very difficult function to write properly.

But, that's the minor half of the bug.  When that cluster allocation
failed, it happened during the cluster duplication phase.
(fat_duplicate_clusters()).  This copies all clusters that will be
outside the new file system into free space.  Writing into free space
should *always* be safe.

When the allocation fails (i.e. allocating space for the cluster's copy),
it should just stop immediately.  The code looks right, and it works
fine here.

The cluster duplication thing is the very first write that Parted does,
so nothing else could/should have damaged your file system.

So, that leaves me without a theory to explain the "trashing" of your
fs.  Have you got any ideas?  Was there any disk activity after it
displayed the error message?  Are you sure it's completely trashed?
(Can you mount it in Linux, for example?)

Any information you can give me might help.

Thanks a lot!
Andrew




reply via email to

[Prev in Thread] Current Thread [Next in Thread]