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

[Bryn M. Reeves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

> 2. I like the idea of creating an ext{3,4} filesystem with the same tool that I do the partitioning.  Its just less hassle.

I like the idea of one tool to do this but I'm not totally convinced it
should be in the partitioning tool.

The lvm2 project has a script called fsadm which aims to provide a
unified interface for manipulating devices and their content. A couple
of years ago I wrote a proposal for a C version (and library) but ran
out of time to get it written.

Imho, something like this that sits a level above parted and related
device or file system manipulation tools would be ideal. Having
something lightweight and simple that provides a clean, consistent
interface seems like it would add significant value. Even better if it
is something that can be easily exported over dbus (for integration with
desktop/server management tools) and have bindings to other
languages/environments added easily.

> 3. I would like parted to have at least filesystem knowledge.  This would allow parted to be more informative to the user when a partition/disk is being handled.  Parted could say something like "dear user, the end size of the partition is smaller than the filesystem you have inside, do you really want to destroy this filesystem?"

I'm not sure that is the job of the partitioning tool. If I am using a
partitioning tool and I want to destroy file systems, I expect the tool
to let me. One of the things I find annoying in parted's current
interface is knowing that the library is able to do certain operations
but that the interface will not allow me to.

Otoh, if I am working with a higher level storage administration tool
that does attempt to "join up" the device and file system administration
into one interface then I *would* want this kind of safety-net checking.

I guess it comes down to the competing forces on parted and its UI: do
we want a powerful, correct partitioning tool for sophisticated users or
do we want a simple, safe storage administration tool for more casual
administrators. Imho there is room for both and value in both, but
trying to cram the two sorts of behaviors into the same user interface
seems to be a rather tall order.

Cheers,
Bryn.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFIgMA86YSQoMYUY94RAiWBAJ9CVwM2zca3Tn6XNfY8C7xew9VPYgCfXLeN
/djAUleoHB0bnyEod8umvVs=
=Om6v
-----END PGP SIGNATURE-----