0

I read about the Lustre file system:

With huge files, it’s unusual for the entire file to be restored to frontend storage

How does Lustre decide how much of a file to restore to front-end storage when a program reads a file?

Franck Dernoncourt
  • 4,987

1 Answers1

2

The statement about huge files in the other comment was a generalization about HSM and not about Lustre specifically. Currently, Lustre will restore the entire file from HSM when an application reads it, even if just one byte is read.

However, this is partly a detail of the way userspace copytools are implemented and not a hard requirement. Lustre can already store different layouts for different parts of a single file, using a composite layout (also called Progressive File Layout, PFL): https://wiki.lustre.org/Progressive_File_Layouts

Some work is underway to allow moving the HSM state into each component, so that it would be possible to archive and restore disjoint parts of a file independently: https://review.whamcloud.com/39387

However, this change is not yet available in any released version.

LustreOne
  • 1,774
  • Thanks. "Currently, Lustre will restore the entire file from HSM when an application reads it, even if just one byte is read.": why does find's sparseness values (%S) sometimes don't go over 1 for non-sparse files? I thought restoring the entire file would imply %S>1 for non-sparse files. – Franck Dernoncourt Mar 12 '24 at 11:43
  • Sparseness > 1 is likely when there are filesystem metadata blocks allocated in addition to the data blocks. With ext4 (ldiskfs) extent-mapped files it is possible in ideal circumstances to have a file up to 4 extents x 127 MiB = 508MiB in size referenced directly from the inode without an external index block, so this would have a sparseness factor == 1.0 until 5+ extents are added to the file. – LustreOne Mar 13 '24 at 16:14