Re: NTFS resize in partman
On Thu, 30 Sep 2004, Joey Hess wrote:
>
> Partman looks at the part of the ntfsresize output that gives a value in
> bytes. That value was, like I said, output as exactly 3231584256 bytes,
> correctly as far as I can tell. No matter what you call a k M or G, a
> byte is a byte.
If I understand you right, you want to say that partman rounded down the
value, so there is bug in partman. This is what you wrote:
"It told me the minimum size was 3.2 gb"
but you didn't explain who is "it". Partman or ntfsresize? Ntfsresize
tells the value in bytes and in MB rounded up, not in GB. And if you made
the conversion to GB then you didn't do it correctly.
> > > [1] clue to ntfsresize developers: if you have to add a
> > > /* WARNING: don't modify the text, external tools grep for it */
> > > then you're doing something wrong; add a new command line option
> > > with a decent interface!
> >
> > What decent interface do you suggest? I'm listening.
>
> ntfsresize --print-min-size <partition>
> # outputs an integral number of bytes followed by a newline
I wish it were so simple.
First of all, it's not a minimum size, it's only an estimate, rtfm, it's
important.
Then there are installers, wrappers that can't parse bigger than 32 bit
numbers. Although this is easy to solve.
On volumes with millions of files or other interesting characteristics the
NTFS consistency check can take time and people want progress bar. I won't
disable the consistency check because there are a lot of already corrupted
NTFS and people need to know that in these cases they must run chkdsk /f
first to be able to resize safely later on. It's very dangerous to resize
an already corrupted filesystem and NTFS tends to corrupt relatively
easily. Of course the progress bar can be optional or sorted out other
way, too.
Then if things don't work out for whatever reason (libc, kernel, hardware,
corrupted NTFS, bad sectors, software bug, etc) then most users and
developers would like to know what exactly went wrong.
So while your interface has indeed a clue from a certain point of view, it
doesn't from usability and supportability ones.
> Later made it into unstable, and testing. In my tests ntfs resize works ok
> with 2.6 kernel and windows continues to boot.
The bootability problem hits only if certain conditions met. Perhaps only
5-10% of all cases. It's also filesystem independent (same problem with
FAT32 too) and it could happen even if the partition was only read (to be
able to read it correctly, parted "fixes" it first). So even partitioning
before installation can't help. The existence of an alien OS is enough.
Szaka
Reply to: