|
From: Szakacsits S. <sz...@si...> - 2003-11-14 06:48:41
|
Hi,
[I got this in private, but I answer to the list, others maybe be also
interested and I think there isn't any secretive in the discussion.
I also answered some of the issues privately earlier, so in the future
I could point to the mailing list archive :)]
On Fri, 14 Nov 2003, Richard Russon wrote:
> > I'm just doing ... work ... before submitting ... changes to do the
> > most general data relocations what people usually would like to be
> > supported by ntfsresize.
>
> Please don't. Not as it stands.
But you didn't even see it :)))
> For the last year or so, I've been trying to sort out all the code.
That's appreciated a lot, believe me. But I also think some of them is
a waste of time. See just below:
> Some of it's been trivial stuff, like standardising the command lines.
Ian Jackson wrote earlier at
http://marc.theaimsgroup.com/?l=linux-ntfs-dev&m=104982728729178&w=2
* I'm slightly disturbed by the amount of option-parsing boilerplate
(and thus clone-and-hack) thats appears in the utilities in the
linux-ntfs 1.7.1 source tree. For example, the stuff to implement the
force, help, verbose, quiet, and version options, and the code that's
needed when opterr=0. Are there any plans to rationalise this, or
should I just follow the example of the other tools ?
I agree with him. Counting the command line parsing errors in a standalone
apps is a waste of time (to implement and maintain). Or you think this will
be the interface for the functionality when the utils move to the library?
I don't think so. At least I've never planned for those I wrote.
> It's been boring work, but I'm trying to turn these tools into something
> professional looking.
>
> Not long back I started utils.c, a repository for common bits of code
> and I went round ripping out the duplicates from other apps, thus
> simplifying them.
>
> My tools tend to have a main() with some options parsing and a call to a
> function with lots of parameters. This is the next stage in the
> evolution. Soon each application becomes a shell that deals with the
> command line and a function that does the work.
Not for ntfsresize. I plan ntfsresize to be only a very short reference
impementation how to use the resize functionality when the core
functionality will be moved to the library. ntfsresize, as a standalone
application, is a very fragile and inefficient interface to partitioning
programs. Working on the options parsing won't make it better.
> And it goes further, the nicely separated function is then moved to a
> separate file, or better still a shared library.
When it's appropriate, to the shared library. To be honest I don't
understand why you put a lot of functions to the separate utils.c file
that must be linked with several apps instead of putting into libntfs.
> ntfsresize contains some useful features, but they are wasted as they
> are.
For others, yes wasted. But it's open source and anybody can move those
features to a shared library, if needs them.
> We currently have separate implementations of cluster find
ntfsresize doesn't _look_ for clusters, it _walks_ all clusters and
relocates what's needed on-the-fly.
> and cluster move.
That's true. But
1) different tools might need different functionality. What I needed
is nobody implemented yet and in the existing ones I didn't find
one to be worth to extend, modify, test, fix, etc. At least not yet.
This doesn't mean they are not ok, only not for me and I don't have
time to try to use them. If you say, they are rock stable and handle
everything I need then I would review, evaluate then use/fix them.
But you wrote "I wouldn't recommend using it yet" and apparently you
test with NT4 what almost nobody uses anymore:
http://www.google.com/press/zeitgeist/sep03_pie.gif
2) In the early stage, I don't see parallel minor implementations a
big drawback. They can "learn" from each other moreover they
can be merged any time, if make sense.
> I haven't written these tools to undermine you, it simply that other
No need for excuse I've never thought that :) It's not a competition, we
are working on the same project. At least the ntldr issue made me think :)
[in file level, I distinguish only $MFT and $MFTMirr].
> people will need their functions and they can't usefully be got at inside
> ntfsresize.
People who asked me I answered. Now I answer here publicly.
> I want to rip out the best bits of each, and get resize to call the
> common code.
From the ntfsresize FAQ:
7. Are there plans for cooperation with Parted?
Yes. Parted is an open source partition manipulation program that also
understands and can modify the filesystems on the partitions. Doing the
support for Parted, before or after implementing full NTFS resize
functionality (resizing fragmented NTFS), depends on users' interest.
So far there were less than 10 such requests compared to the several
_orders_ bigger "please support fragmented volumes".
> In this method, I'm starting ntfsck. It will start with the bitmap
> checking from resize.
Cool. I wrote about this here:
http://marc.theaimsgroup.com/?l=linux-ntfs-dev&m=105949711324625&w=2
- design, write an ntfs_walk_clusters_by_<inode|mft>() function. It's
what at least ntfsresize, ntfsclone, ntfsmeta already have
(walk_inodes()) but it must be a function. One if its parameter
is a struct with many callbacks at different points during the walk.
Please also consider it must be possible to have the callbacks linked at
each stages. E.g. ntfsresize does the consistency check _and_ the shrink
constrains collection at the same inode walking time. Doing them separately
is a big performance hit (twice as slow).
> Thank you for putting up with the possibly patronising words above.
> Now I get to the harsh words. I meant to say these sooner, but I've
> been biting my tongue. I don't think that's benefited either of us.
>
> ntfsresize is an embarrassing mess.
>
> It is a maze of global variables
There are 2 global variables. Please see them here:
http://linux-ntfs.bkbits.net:8080/ntfsprogs-devel/anno/ntfsprogs/ntfsresize.c@1.53?nav=index.html|src/|src/ntfsprogs
ntfs_volume *vol = NULL;
and
struct bitmap lcn_bitmap;
lcn_bitmap could be attached to ntfs_resize_t and the variable that uses
this structure is local and passed between functions. It's one minute to
implement.
'vol' is trickier because it needs _designing_ how the library interface
will be for the resizing. There are several ways to do it but I didn't
think about it long because it's not high priority (see above).
> and exit statements.
That's a very important implementation issue. It makes sure when something
would go unexpected, ntfsresize quites immediately. No even cleanup!
Cleanup is done by the OS, not the app that became unreliable. If I did
cleanup it could mess up things unpredictable. Now it's proven, any time
ntfsresize would unexpectedly quit, the scheduled Windows chkdsk is able to
correct the volume.
Anyway, long story and it needs care. Priority, free time and benefit wise
it was never on the top. I've seen fixing it a high risk.
Nevertheless the new code started to fix some of these because it's
_needed_ with the _new_ code to keep the volume consistent or recoverable
if an unexpected or still unsupported case is hit.
> If you ever get around to integrating resize into another program, that's
> all got to change.
Sure. It's just not the highest priority (i.e. what people request most).
> There are three ways a program call our code: exec, load or compile.
> At the moment everything's relying on exec. It's an awful, clumsy
> method, but it works. ntfs.so is too low a level to be useful, so we
> could use application-level shared lib ntfsapps.so.
Aha! Now I understand why you're doing some of the things that didn't make
any sense before.
However I think ntfsapps.so doesn't sound very good. Maybe one lib between
the two levels, if you don't want too feature rich libntfs (already 65 kB
but I think a _LOT OF_ duplicated code could be removed from there also).
Of course having more libs will result more problems (see e.g. people
having problems with reiserprogs, progsreiser, etc).
> Our tools are useful, already, but there is so much room for improvement.
There is always, everywhere :) That's why prioritizing shouldn't be
completely neglected. Just do whatever you think is important, my only
request is, please regard the working functionality.
Cheers,
Szaka
|
