Extreme? [LWN.net]

Extreme?

Posted Jan 23, 2012 23:26 UTC (Mon) by dgc (subscriber, #6611) [Link]

I guess I didn't explain that particularly well :/

By "flag day" I mean this is a complete superblock version bump, not a new set of feature bits that some subset of the new features can be selected at mkfs time. IOWs, the on-disk format changes are an all-or-nothing change that will all land in a single release, so the functionality is either supported or it isn't....

By "No attempt to provide backwards or forwards compatibility for format changes" I mean that there is no attempt to:

- restrain the change of format in a way that older kernels can still read the metadata even in read only mode (no backwards compatibility)
- locate (and potentially limit) the new metadata fields in a way that an old format can be upgraded in place just via an on-the-fly RMW cycle (no forwards compatibility)

Hence we can simply modify the metadata block headers or records to add the new information rather than have to try to find random unused holes or padding in the metadata to locate everything. And because all XFS metadata has magic numbers in it, we can easily tell the difference between metadta formats by changing the magic numbers - that's another reason why self-describing metadata is important...

FWIW, the "find and use holes/padding" is the approach ext4 is taking to adding CRCs, so in some places they are having to use a weaker CRC (CRC16 instead of CRC32c) because there is only 16 bits of unused space in the metadata block. This is being done because the ext4 developers want to support offline addition of CRCs to a filesystem.

This, however, is exactly the sort of "compromised on-disk format" we want to avoid because it makes the implementation more complex and it doesn't provide all the information we need to detect errors that we know can happen and need to protect against. That's not an acceptable trade-off for the storage capacities we expect to be supporting in 5 years time....

I hope it's a bit clearer what I meant now ;)

Dave.

Extreme?

Posted Jan 23, 2012 23:39 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

so restating what I think you are saying

old kernels will not be able to use the new format (even in read-only mode)

new kernels will be able to use both the old and new format

once a filesystem is converted, there will be no way to 'unconvert' it.

This sounds reasonable (although may still be reason enough to call it XFS2 even if it's the same codebase supporting both on-disk formats)

what you initially said sounded more like

old kernels will not be able to use the new format

new kernels will not be able to use the old format

when you upgrade the kernel you will be forced to convert the filesystem, and there is no way to unconvert it.

This is not acceptable and is the reason people were concerned.

Extreme?

Posted Jan 24, 2012 0:18 UTC (Tue) by dgc (subscriber, #6611) [Link]

> old kernels will not be able to use the new format (even in read-only mode)

Correct.

> new kernels will be able to use both the old and new format

Correct.

> once a filesystem is converted, there will be no way to 'unconvert' it.

There is no "convert" or "unconvert" operation - the format is selected at mkfs time and it is fixed for the life of the filesystem. That's an explicit design decision (as I've previously described)....

> This sounds reasonable (although may still be reason enough to call it
> XFS2 even if it's the same codebase supporting both on-disk formats)

A name change would only cause confusion. XFS has a history of mkfs-only selectable format changes over time and this change is being handled in exactly the same manner as all the previous ones that have been made. If XFS was renamed every time the on-disk format changed then it would be XFS 17 by now. ;)

Dave.