[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linux-NTFS-Dev] Re: Re: ntfs resize and gtk frontends
Re: [Linux-NTFS-Dev] Re: Re: ntfs resize and gtk frontends
Fri, 23 Jan 2004 21:12:55 +1100
On Fri, Jan 23, 2004 at 02:19:02AM +0100, Szakacsits Szabolcs wrote:
> > This patch only solves half the problem. I guess it's the important
> > half though. (The other half is getting Parted to talk to you in
> > custom units)
> Couldn't that part be used/applied until the left is done? I mean, would
> it add extra functionality without breaking things?
Yes. It might be a bit confusing, but I don't think this is a good
reason not to include the patch.
> > Besides, this usually isn't a problem, because things get rounded
> > in a big way for alignment stuff.
> I would be interested how this rounding happens.
> [cs]fdisk has the "problem" it rounds sometimes ceiling sometimes floor to
> cylinder boundary. Thus if one follows the rule for shrinkage "make the
> partition bigger than the filesystem" found in the resize2fs,
> resize_reiserfs and ntfsresize man pages then he/she can end up in a
> situation where the partition end being in the middle of the filesystem.
> So just trying the logic
> 1. resize fs to 'X'
> 2. resize partition to 'X' + 'Y' where 'Y' > 0
> isn't guaranteed to work if 'Y' isn't big enough because the tools can
> round down enough to cylinder boundary to cause this problem. I don't know
> how ext and reiserfs handle this but NT4, W2K, XP, W2K3, etc won't
> boot [well, probably it's better than crashing half/one year later]. Just
> by recreating the partition to be bigger fixes the problem (many people
> had this).
> In short, they should always round ceiling to avoid this problem. If it's
> possible of course.
This is one of my favourite stories!
Parted's algorithm works like this:
(1) user requests to resize to [X, Y] (where X = start, Y = end)
(2) Parted requests from the file system code the resize
constraint. This is a fairly simple data structure containing
min/max size, and congruences for alignment.
For example, if the blocksize is 4k, and the resizer
can only add/remove to the start in units of 4k, then the
alignment constraint on the start might look like:
X = 1 sector (mod 8 sectors)
(3) Parted asks the partition code to find the closest
permissible match to [X, Y] that simultaneously matches
the file system constraint (passed as a parameter), and
the partition table constraints. Eg: the msdos code might
add this constraint for a logical partition (cylinder crap,
needs to be on the second head):
X = 1 (mod 63 sectors)
The partition table code uses ped_constraint_solve() and
ped_constraint_intersect(). The PedConstraint structure
has the nice property that the intersection of any pair
of PedConstraints can also be represented by a PedConstraint.
This is a result of the Chinese Remainder Theorem from
(4) if the closest permissible match is a long way from [X, Y],
Parted tells the user, and asks them if they want to continue
So, since the resizer's (or mkfs'/whatever) constraint is always
respected, there should be no possibility for problems. Before this
constraint system was introduced, Parted regularly had major problems
with this stuff... the code for doing this stuff was totally
The Chinese Remainder Theorem saves the day!
> > > - no save/restore partition table functionality. Partitioning is very
> > > messy, complicated, a lot of scenarios. When somethings goes wrong
> > qtparted allows you to "commit".
> I didn't check it out yet but I've seen some messages when people were
> confused what's happening. Well, I admit I don't know what's the
> "traditional" way to do these with GUI ...
Yeah, GUI design is hard.
At least confusion is unlikely to lead to data loss... just wasted
> > I think this is a better solution (but both features are good)
> The other feature has another benefit what I forgot to mention earlier.
> Debug, troubleshooting. If there is a problem then user could just send
> the file for investigation, bug reproduction.
> > > - "report this .... bug" instead of "check out ... for updates, etc"
> > > Unfortunately there isn't any Changelog/FAQ on the Parted site, not to
> > > mention link to the latest release.
> > Is this really important? Perhaps we should have a separate bug
> > list to the main list.
> I don't think a new list is needed but
> - announcements of the new versions or just stating the latest
> stable release version, data (or so) on the Parted web page
> - better logging of errors (probably should be to a file) and
Which file? Where could it be saved?
> asking users to send that
> could contribute for improving things in the long term (easier bug fixes
> and more free time since no "need" to answer the same questions => better
> user satisfaction).
Actually, I've found that users really like the personal contact.
Not that that's a good reason :p
> > I think it's best to minimize the time users have to spend to report
> > a bug - otherwise they won't bother.
> Of course I agree. "If you can reproduce this bug with the latest version
> found at .... please send the 'parted.log' file.... ". Etc.
Perhaps a better solution would be to create some kind of hash
of the bug report message (which includes version number), and they
can type that hash in to see if a problem matching that description
has been fixed.
> [ parted in ocaml ]
> > > I'm afraid it wouldn't be :)
> > I would like it, if that counts!
One thing with O'Caml: would it make it difficult to interface
libocamlparted with distro installers? I haven't used O'Caml, but I
have enjoyed playing with Haskell a bit, and have heard O'Caml is much
less painful for doing IO.
> > > - most distros ship parted but I don't know any who ships ocaml
> > Debian :)
> Well, in that case Mandrake also :)
Anyway, what dependencies would ocaml add?
(some kind of libocaml?)
I see you and Sven agree that the dependencies are small enough for a
PS: I just registered an alioth project for Parted. Waiting for approval...