Re: resize + cp -> wrong size + request for help

[Ross Boylan]

Thanks for your rapid and thorough response.  A bit of follow-up appears below.

On Fri, Nov 30, 2001 at 09:55:21AM +1100, Andrew Clausen wrote:
> On Thu, Nov 29, 2001 at 11:50:37AM -0800, Ross Boylan wrote:
> > 1) This seems like a bug.  It may be significant that /hdc6 showed as
> > ext3 on one diagnostic before I did anything.  Also, I ran e2fsck in
> > the middle of things--maybe it fixed the wrong size?
> 
> The problem is you didn't quit parted before using other tools to look
> at the file system.  The buffer cache for /dev/hdc and /dev/hdc6
> were out of sync, so you had some buffers that were "old", and some
> "new".

Does "other tools" refer to mke2fs (or perhaps my umount?) or can even
something innocuous like ls or a file browser cause the problem?

> 
> > 2) What's the best way to fix this?
> 
> In the next stable branch of Parted (i.e. 1.6.x), Parted will flush
> the caches after every "dangerous" operation.

I meant just fixing the damage on my disk.  From your remarks below,
it sounds as if I should just reformat and try again.

> 
> > 3) Is there any way to recover the contents of /hdc6 before the cp?
> 
> No.  The ext2 cp does a raw block copy, that basically obliterates
> everything :(

Just out of curiosity, aren't there some absolute sector references
embedded in the file system?

> 
> > 4) Consider changing the name of the cp command to replace or
> > something similar.  I thought it was going to add to the files that
> > were already on the partition, not replace them.  Though the behavior
> > is documented in the manual (too bad I didn't read it!) it is
> > unexpected behavior for cp.
> 
> I disagree.  If you do "cp /etc/fstab /etc/mtab", you expect to
> lose /etc/mtab, right?  You only get the "add" behaviour for
> directories.  /dev/hda5 is a device (i.e. a file, a single linear
> address space), not a directory.

As I said, I know there's a case to be made that the cp is OK.  It
just seems pretty easy to interpret it the other way, and giving it
some other name makes the program more idiot-proof.

> 
> > 5) I'm not sure what would have happened if I specified a different
> > start than the existing one (given the warning parted can't move the
> > start) or an end past the legal reason.  I hope that's safe.
> 
> It's safe.  Parted (is designed to... no legal guarantee) to never
> do something "stupid", like obliterate a file system.  It has
> a constraint solver, heaps of sanity checks, warnings, etc.
> 
> > Megabytes are not natural units for this problem, and it would be nice
> > to add the ability to specify postion by other means (cylinder, CHS,
> > sector) and also to have a separate command extend that only moves the
> > end.
> 
> I intend to add support for other units.  CHS is completely unnatural.
> It isn't even well-defined.  Perhaps gigabytes would be more appropriate
> nowadays?

Though CHS is unnatural, it is one way (and originally the canonical
way) the partition table is specified, even though the large size of
disks has rendered it pretty useless.  So it seems natural for a
partition manager to work in those terms.  I certainly wouldn't put it
high on the to-do list, however.  Gigabytes would be useful.

One issue with other units (excepting cylinders) is that it's pretty
easy to end up on a non-cylinder boundary.  I gather at least some
tools and systems don't like that.  Perhaps there could be an option
for rounding to the boundaries, or a warning if you're off them?

> 
> > Also, some default behavior to fill available space would be
> > nice.  I know it's easier to wish for these things than do them :)
> 
> That's too high-level.  Should be part of another tool (that uses libparted)
> IMHO.
> 
> OTOH, 1.5.x (unstable) introduces a default interface.  I.e. if you
> don't supply enough parameters, it will ask you for them, and will
> offer you a default choice.  That default could be "the maximum",
> and you get your desired behaviour for free ;)
> 
> Andrew
> 


P.S.  Of course, if you added NTFS that would be great.  The NTFS
driver for Linux seems pretty stable for reading, but I suppose it
needs to be stable for writing to even think about borrowing from it
for NTFS move/resize.