linux-ext4 - Re: [PATCH 01/11] ext4: add handling for extended mount options

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <7AD1A611-9BD2-4F32-9568-D0A517047EF0@dilger.ca>
Date:   Tue, 23 Jul 2019 15:59:42 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Harshad Shirwadkar <harshadshirwadkar@...il.com>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 01/11] ext4: add handling for extended mount options

On Jul 22, 2019, at 3:02 PM, Theodore Y. Ts'o <tytso@....edu> 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






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)