Re: [PATCH v4 2/9] fs: add infrastructure for multigrain inode i_m/ctime

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, May 20, 2023 at 07:21:57PM -0700, Boqun Feng wrote:
> [Cc Paul and Mark]
> 
> On Sat, May 20, 2023 at 04:06:43PM -0400, Theodore Ts'o wrote:
> > On Thu, May 18, 2023 at 07:47:35AM -0400, Jeff Layton wrote:
> > > Use the 31st bit of the ctime tv_nsec field to indicate that something
> > > has queried the inode for the i_mtime or i_ctime. When this flag is set,
> > > on the next timestamp update, the kernel can fetch a fine-grained
> > > timestamp instead of the usual coarse-grained one.
> > 
> > TIL....  that atomic_long_fetch_or() and atomic_long_fetch_andnot()
> > exist.  :-)
> > 
> > When I went looking for documentation about why they do or this
> > particular usage pattern found in the patch, I didn't find any --- at
> > least, certainly not in the Documentation in the kernel sources.  The
> > closest that I fond was this LWN article written by Neil Brown from
> > 2016:
> > 
> > 	https://lwn.net/Articles/698315/
> > 
> > ... and this only covered the use atomic_fetch_or(); I wasn't able to
> > find anything discussing atomic_fetch_andnot().
> > 
> > It looks like Peter Zijlstra added some bare-bones documentation in
> > 2017, in commit: 706eeb3e9c6f ("Documentation/locking/atomic: Add
> > documents for new atomic_t APIs") so we do have Documentation that
> > these functions *exist*, but there is nothing explaining what they do,
> > or how they can be used (e.g., in this rather clever way to set and
> > clear a flag in the high bits of the nsec field).
> > 
> > I know that it's best to report missing documentation in the form of a
> > patch, but I fear I don't have the time or the expertise to really do
> > this topic justice, so I'd just thought I'd just note this lack for
> > now, and maybe in my copious spare time I'll try to get at least
> > something that will no doubt contain errors, but might inspire some
> > folks to correct the text.  (Or maybe on someone on linux-doc will
> > feel inspired and get there ahead of me.  :-)
> > 
> 
> Paul already started the work:
> 
> 	https://lore.kernel.org/lkml/19135936-06d7-4705-8bc8-bb31c2a478ca@paulmck-laptop/

Which reminds me, I need to forward-port that documentation to Mark's
latest version.  ;-)

							Thanx, Paul



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux