XFS parent pointers [LWN.net]

XFS parent pointers

Posted May 7, 2018 18:08 UTC (Mon) by k8to (guest, #15413)
Parent article: XFS parent pointers

Could you label your file with a particular xattr to cause online scrub to move your file somewhere you normally wouldn't be able to place it?

XFS parent pointers

Posted May 8, 2018 1:39 UTC (Tue) by dgc (subscriber, #6611) [Link] (8 responses)

> Could you label your file with a particular xattr to cause online scrub to move your
> file somewhere you normally wouldn't be able to place it?

No. These parent pointer xattrs will be in a private xattr namespace that only the kernel code can access. Essentially they are part of the metadata of the filesystem, and users cannot access filesystem metadata directly.

-Dave.

XFS parent pointers

Posted May 8, 2018 6:52 UTC (Tue) by dgm (subscriber, #49227) [Link] (2 responses)

Unless they can modify the filesystem on disk, that is.

XFS parent pointers

Posted May 8, 2018 14:52 UTC (Tue) by k8to (guest, #15413) [Link]

At which point, presumably they could put the file anywhere anyway.

XFS parent pointers

Posted May 8, 2018 22:32 UTC (Tue) by dgc (subscriber, #6611) [Link]

> Unless they can modify the filesystem on disk, that is.

And that, folks, is why we don't let anyone other than root access block devices directly or mount filesystem images.

Because if anyone can modify the filesystem on disk then we're completely and utterly screwed, parent pointers or not. And that goes for any filesystem that doesn't have a cryptographically secure on-disk format (e.g. XFS, ext4, btrfs, f2fs, etc). i.e. no filesystem except maybe bcachefs is robust against such tampering.

-Dave.

XFS parent pointers

Posted May 8, 2018 19:07 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

This doesn't mean an extra block allocated per file, right? For files without (many) xattrs, presumably this is small enough to get packed in with existing metadata? (The space usage for an extra block for filesystems containing many very small files might be quite painful, not to mention the disk seeks -- though XFS is damn good at keeping those down these days. :) )

XFS parent pointers

Posted May 8, 2018 22:27 UTC (Tue) by dgc (subscriber, #6611) [Link] (2 responses)

> This doesn't mean an extra block allocated per file, right?

In most cases there will be no extra allocation - the xattr will easily fit inside the inode for typical single parent, short name files on a default 512 byte inode filesystem. It's not until you have multiple hard links or filenames > 100 bytes that the xattrs will tend to go out of line. Or you have lots of other xattrs, in which case they're at risk of being moved out of line, anyway. If you're really worried about xattrs being kept in line, then you can always format the filesystem with 1kB or 2kB inodes....

-Dave.

XFS parent pointers

Posted May 9, 2018 15:51 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Oh right. I'm only worrying because I'm hacking up a replacement for GNU Stow that uses hardlinks where possible, unstowing by comparing the st_dev/st_ino of appropriately-located files in the target and stow tree, to reduce the visible behaviour change GNU stow and graft can cause with their huge symlink farms (since lots of programs care whether things are symlinks or not but almost none check their own read-only files to see what their link count is). If this works, systems that use it would end up with hundreds of thousands of files with link count 2.

However, I suspect that for your average file, two hardlinks is fine for inline storage of the parent pointers as well (inodes aren't *that* small). If a file has ten twenty or fifty hardlinks, I'd frankly *expect* parent pointers to be moved out of line. :)

XFS parent pointers

Posted May 21, 2018 1:54 UTC (Mon) by njs (subscriber, #40338) [Link]

FYI in case you're looking for other projects that make similar demands, conda is also a heavy user of hardlinks, for a somewhat similar use case.

XFS parent pointers

Posted May 9, 2018 3:54 UTC (Wed) by k8to (guest, #15413) [Link]

Thank you for the clarification!