[parted-devel] [PATCH] Document the lack of support for ext3 filesystems.

[Joel Andres Granados]

Bryn M. Reeves wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jim Meyering wrote:
>> "Bryn M. Reeves" <bmr at redhat.com> wrote:
>>> Joel Andres Granados wrote:
>>>> Jim Meyering wrote:
>>>>> Hi Joel,
>>>>>
>>>>> Thanks for the patch.
>>>>> Deprecating ext3 support is a good first step.
>>>> yep, its all good.  My idea is not to take it away completely though.  The more I think about this issue the more I realize why it was put there in the first place.
>>>> Reasons that I think we should support ext3:
>>>> 1. There is a library, makes things easier and makes stuff less prone to bugs.
>>> Which library do you mean here? The last time I looked the library
>>> interfaces provided by e2fsprogs were themselves quite low-level. E.g.
>>> resize2fs is implemented on top of libext2fs but all the smarts for the
>>> resize operation are implemented in resize2fs itself (apart from online
>>> which relies more on kernel support).

The library is very low level.  Actually my experience with the e2fsprogs thing is a little bit unexpected.  All the magic happens somewhere else different from the library calls.  Of course I didn't know that some weeks ago. :/

>>>
>>> I think it is unwise to reinvent this kind of low-level file system
>>> manipulation code - if there's no direct library interface available I
>>> would prefer to wrap the executables rather than implement it in parted
>>> (or anywhere for that matter) and repeat the mistakes of
>>> libparted/fs/ext2/ext2_resize.c.
>> Thanks for writing all that.
>> That was exactly my impression when I looked into making
>> parted use e2fsprogs library code.  I certainly did not
>> want to duplicate all of that logic in parted.
> 

I agree with this.  It will inevitable be duplicating the logic.  However, I'll try to finish the project as a proof of concept, to see how exactly the library would fit into the code and then decide if its worth presenting....

> It would be really great if each *fs project would implement a
> programmatic interface to its tools that had some semblance of a
> standardised interface.
> 
> This is also something I was thinking of while designing fsadm - that we
> could start off with a generic exec wrapper that could interface to any
> set of file system specific tools (providing e.g. format specifiers and
> expect-style output parsers to ease parameter passing/response parsing)
> but eventually move towards a state where we'd hash out a uniform
> interface that file system implementors could conform to in order to
> have their tools easily plug into the fsadm framework (e.g. e2fsprogs
> might supply a fsadm-e2fsprogs.so, or something).
> 
> That would all depend on getting sufficient buy-in for the "grand
> unified storage tool" concept to actually get a critical mass of file
> systems on board but it's something I could see beeing very useful.
> 
> And of course, we still need to decide if/where we want to implement
> file system stuff in the first place...
> 
> Cheers,
> Bryn.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFIgNRR6YSQoMYUY94RAm89AKDAOdoEEy7DIzJF6bjSBQQN2abtqgCcC9qt
> Br4jgJoyo6MTUAQxq8CvvXU=
> =VMxm
> -----END PGP SIGNATURE-----


-- 
Joel Andres Granados
Red Hat / Brno, Czech Republic