On Jul 22, 2019, at 3:02 PM, Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > > On Mon, Jul 22, 2019 at 12:15:11PM -0600, Andreas Dilger wrote: >> Unless I missed it, this patch series needs a 00/11 email that describes >> *what* "fast commit" is, and why we want it. This should include some >> benchmark results, since (I'd assume) that the "fast" part of the feature >> name implies a performance improvement? > > For background, it's a simplified version of the scheme proposed by > Park and Shin, in their paper, "iJournaling: Fine-Grained Journaling > for Improving the Latency of Fsync System Call"[1] > > [1] https://www.usenix.org/conference/atc17/technical-sessions/presentation/park > > I agree we should have a cover letter for this patch series. Also, we > should add documentation to Documentation/filesystems/journaling.rst > about this feature; what it does, how it works, its basic on-disk > format changes, etc. Thanks for the link, I hadn't read that paper previously. From reading the paper, it seems there are some things that should be addressed before the patch is committed to the tree in order to maintain proper disk format compatibility: - the ijournal header shows a 256-byte inode. In Lustre today (and also Samba and other xattr-intensive workloads) 512- or 1024-byte inodes are used in order to store more xattrs within the inode, so the size of the inode data in the ijournal header needs to match the actual inode size of the filesystem and not be a fixed size. What if the inode size == blocksize? - the ijournal header also shows a 4-byte inode number. It would be prudent to reserve space for 64-bit inode numbers, or at least have some mechanism (flag) to indicate that a 64-bit inode is stored instead of a 32-bit inode. - if there are many cores in a system, say 96, how much space will be used from the journal file by the per-core ijournal? - what happens if multiple threads are writing to the same file with ijournal and per-core ijournal areas? Will the same inode information be recorded in multiple ijournal areas? Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
