Re: [Linux-NTFS-Dev] Re: Re: ntfs resize and gtk frontends
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[23] 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 Number Theory. (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 anyway. 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 unmaintainable. 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 time. 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. Good point. - 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? Maybe syslog? 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
Re: [Linux-NTFS-Dev] Re: Re: ntfs resize and gtk frontends
On Fri, Jan 23, 2004 at 09:12:55PM +1100, Andrew Clausen wrote: [ 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. Huh, you are all seriously considering this ? phone call with Andrew ... Well, as said, i will try to make a little toy implementation in the next month or so, which would support amiga partition table writing (the one i have experience with), and include both a ocaml text frontend, and a C-binding library which should be as near as possible to libparted, and either parted on top of that, or a smallish C frontend. - 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?) Well, ocaml can be both bytecode and native code. The bytecode is arch independent, and maybe 2-3 times slower than the native code, but i doubt speed is of importance here. As dependency, bytecode stuff needs the ocaml virtual machine, which is 111372 of size. native code can be smaller. There would maybe also be need of some of the ocaml libraries, but not that much. Mostly the Int64 module for 64bit integers, i think. The ocaml-base package contains all the needed stuff for bytecode and is : Package: ocaml-base Depends: libc6 (= 2.3.2.ds1-4), libgdbm3, libncurses5 (= 5.3.20030510-1), tcl8.4 (= 8.4.2), tk8.4 (= 8.4.2), xlibs ( 4.1.0) Many of them would not be really needed in a smallish implementation. all the tcl/tk iand x11 stuff we can remove for example. The size of this package is 149942 though, but it contains all the libraries, and we maybe don't need all that. And naturally, for native code, it would be different, but let's see once i have written something. I see you and Sven agree that the dependencies are small enough for a boot disk. Not sure, but let's give this thing a try. If nothing else it would be an interesting project. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Linux-NTFS-Dev] Re: Re: ntfs resize and gtk frontends
On Fri, 23 Jan 2004, Andrew Clausen wrote: This is one of my favourite stories! Talking about favourites, here is my favourite challange. Since earlier ntfsresize could resize only if there weren't data after the new size, many people made the compromise ok, let's shrink here now and more later on when/if I need/can and some ended up in this situation: hda1 primary NTFS hda2 primary linux hda3 primary linux hda4 extended hda5 logical linux ... Where could they put the space gained at the end of hda1 _without_ changing and renumbering hda2, hda3, hda5? AFAIS nowhere. What would be the least pain for them? Merging the free space with hda2 but that's not supported (it could also break Linux boot, e.g. LILO used and hda2 has the kernel). - better logging of errors (probably should be to a file) and Which file? Where could it be saved? Maybe syslog? Syslog seems overkill, probably not everywhere available, a bunch of unrelated messages, harder to get the info to recreate a problem (basically user defined format). But opening a file should work everywhere. Well, 'write' maybe not but most should have at least one read/write directory, probably /tmp. So it could be in /tmp or current directory or in /var/log or ... and make sure the user takes steps, if it's needed, the file won't get lost when the box is rebooted. 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. I thought about this also (Etc above :) The simplest implementation would be the 'Parted FAQ'. PS: I just registered an alioth project for Parted. Waiting for approval... Cool :) Cheers, Szaka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Linux-NTFS-Dev] Re: Re: ntfs resize and gtk frontends
* Szakacsits Szabolcs [EMAIL PROTECTED] [040123 12:49]: This is one of my favourite stories! Talking about favourites, here is my favourite challange. Since earlier ntfsresize could resize only if there weren't data after the new size, many people made the compromise ok, let's shrink here now and more later on when/if I need/can and some ended up in this situation: hda1 primary NTFS hda2 primary linux hda3 primary linux hda4 extended hda5 logical linux ... Where could they put the space gained at the end of hda1 _without_ changing and renumbering hda2, hda3, hda5? AFAIS nowhere. What would be the least pain for them? Merging the free space with hda2 but that's not supported (it could also break Linux boot, e.g. LILO used and hda2 has the kernel). I think the main problem is no primary partition is left. If hda4 would be free, one could try if modern programm still support having hda4 physically between hda1 and hda2... Hochachtungsvoll, Bernhard R. Link -- The man who trades freedom for security does not deserve nor will he ever receive either. (Benjamin Franklin) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
