[PATCH, RFC] Add support for external log devices for XFS and ext3/4

Julien BLACHE jblache at debian.org
Thu May 27 13:00:53 CEST 2010


Michael Tautschnig <mt at debian.org> wrote:

Hi,

>> There are two approaches to this issue:
>>  - delay all mkfs commands until all the devices have been set up
>>    (physical devices, RAID, LVM, cryptsetup ...)
>>  - integrate external journals into setup-storage
>> 
>> I went with the latter because the former requires more profound changes
>> in setup-storage and I think it's not worth it/better this way.
>
> I fully concur - I believe the first approach would be a really really ugly
> hack. Parsing createopts is really something I'd like to avoid...

Yes. Actually, this started with XFS support only as that's what I was
going to use. Unlike ext3/4, XFS takes care of both the log device and
the data device when calling mkfs.xfs, so the first option was viable
for XFS.

Unfortunately, ext3/4 is totally ruining the party by requiring two mkfs
calls, one for the log device and one for the FS itself, in this order.

>> disk_config /dev/sda fstabkey:uuid
>> primary    -         256    ext3_journal              -
>> primary    -         256    ext4_journal              -
>> primary    -         256    xfs_journal               -
>> logical    /        2000    ext4:journal=/dev/sda2    defaults
>> logical    /home    2000    xfs:journal=/dev/sda3     defaults
>> 
>> disk_config /dev/sdb fstabkey:uuid
>> primary    /foo      10-    ext3:journal=/dev/sda1    defaults

> Hmm, the _journal stuff feels a bit like a hack. Couldn't one just have "-" or
> ext4 in there and say "-O journal_dev" in createopts?

That would require parsing createopts to determine what it is we're
formatting, and just like you, I'd rather avoid that.

Conceptually, the log device for ext3/4 is another filesystem, so I
think it's better to treat it as such. I tried other things and it did
not really go well :/

I also find it's a lot easier when reading the disk_config, as you don't
have to look at another column to determine what the FS really is for.

> Arguably, that requires a bit more typing, but the code to process the
> _journal entries feels hackish. It requires a lot of special-casing...

There isn't that much special casing, outside of building the mkfs
commands (and even there, I think I managed to keep that pretty clean),
it's a couple lines top. Plus, the special casing only has to be done on
the _journal suffix, so it's pretty clear what it is about and generic
for all journal types.

Let me add that the patch you're seeing is the 4th or 5th incarnation of
this code and of everything I've come up with, it's the nicest (and
shortest) of all. There have been some true horrors in the pile :)

JB.

-- 
 Julien BLACHE <jblache at debian.org>  |  Debian, because code matters more 
 Debian & GNU/Linux Developer        |       <http://www.debian.org>
 Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


More information about the linux-fai-devel mailing list