XFS Online Repair Functionality To Undergo A Massive Design Review

[phoronix]

Phoronix: XFS Online Repair Functionality To Undergo A Massive Design Review

The XFS file-system updates have been submitted and merged for the ongoing Linux 5.18 merge window...

https://www.phoronix.com/scan.php?pa...18-XFS-Changes

[waxhead]

I am quite biased towards BTRFS, but this is really interesting news. I have not looked much into XFS in recent years, and I assume that the online repair is only for metadata, but it is still a step in the right direction. Last thing I heard was that XFS was working on copy on write and subvolumes , but I assume that bad data can not be detected (no checksums??) - is this still true?

[uxmkt]

XFSv5 has CRCs (see mkfs.xfs / xfs_info). CoW is done (cp --reflink a b).

# xfs_info /
meta-data=/dev/mapper/cr-auto-1 isize=512 agcount=16, agsize=7806160 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1 bigtime=0 inobtcount=0

[splatterlight]

crc=value
This is used to create a filesystem which maintains and checks CRC
information in all metadata objects on disk. The value is either 0 to disable
the feature, or 1 to enable the use of CRCs.

Key word metadata. You still have to punt to the block layer if you want data integrity.

[jacob]

crc=value
This is used to create a filesystem which maintains and checks CRC
information in all metadata objects on disk. The value is either 0 to disable
the feature, or 1 to enable the use of CRCs.

Key word metadata. You still have to punt to the block layer if you want data integrity.

As Linus once said, users care about their data, not metadata. There is no point in having great consistent metadata if the data themselves are corrupt.

[waxhead]

As Linus once said, users care about their data, not metadata. There is no point in having great consistent metadata if the data themselves are corrupt.

Well if the data is stored on BTRFS backups and XFS is able to let you know what file(s) went toast then it might be a viable solution still.

[jacob]

Well if the data is stored on BTRFS backups and XFS is able to let you know what file(s) went toast then it might be a viable solution still.

But it can't, that's the thing. XFS has no mechanism to detect data (file content) corruption. I don't see how it could even be implemented without data (not just metadata) COW.

[microcode]

XFSv5 has CRCs (see mkfs.xfs / xfs_info). CoW is done (cp --reflink a b).

# xfs_info /
meta-data=/dev/mapper/cr-auto-1 isize=512 agcount=16, agsize=7806160 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1 bigtime=0 inobtcount=0

Is there a way to make CoW the default behaviour for something like that, or is that a tools issue?

[trubicoid2]

Is there a way to make CoW the default behaviour for something like that, or is that a tools issue?

You can do an alias for cp to be cp --reflink=auto

alias cp='cp --reflink=auto --sparse=always'

[uxmkt]

Is there a way to make CoW the default behaviour for something like that, or is that a tools issue?

The alias command should likely be alias cp='/bin/cp ..' just to avoid running into a recursion. Anyway, even btrfs does not auto-cow on cp, or does it? (TTBOMK it only does that when making a dedicated snapshot with e.g. `btrfs sub snap`.)