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

[Bryn M. Reeves]

-----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).
>>
>> 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.

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-----