[lkml]   [2010]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [PATCH V3 0/8] Cleancache: overview
    > From: Boaz Harrosh []
    > Sent: Tuesday, August 03, 2010 10:23 AM
    > To: Dan Magenheimer
    > Subject: Re: [PATCH V3 0/8] Cleancache: overview
    > On 07/24/2010 12:17 AM, Dan Magenheimer wrote:
    > >>> On Fri, Jul 23, 2010 at 06:58:03AM -0700, Dan Magenheimer wrote:
    > >>>> CHRISTOPH AND ANDREW, if you disagree and your concerns have
    > >>>> not been resolved, please speak up.
    > >>
    > >> Hi Christoph --
    > >>
    > >> Thanks very much for the quick (instantaneous?) reply!
    > >>
    > >>> Anything that need modification of a normal non-shared fs is
    > utterly
    > >>> broken and you'll get a clear NAK, so the propsal before is a good
    > >>> one.
    > >>
    > >> No, the per-fs opt-in is very sensible; and its design is
    > >> very minimal.
    > >
    > > Not to belabor the point, but maybe the right way to think about
    > > this is:
    > >
    > > Cleancache is a new optional feature provided by the VFS layer
    > > that potentially dramatically increases page cache effectiveness
    > > for many workloads in many environments at a negligible cost.
    > >
    > > Filesystems that are well-behaved and conform to certain restrictions
    > > can utilize cleancache simply by making a call to cleancache_init_fs
    > > at mount time. Unusual, misbehaving, or poorly layered filesystems
    > > must either add additional hooks and/or undergo extensive additional
    > > testing... or should just not enable the optional cleancache.
    > OK, So I maintain a filesystem in Kernel. How do I know if my FS
    > is not "Unusual, misbehaving, or poorly layered"

    A reasonable question. I'm not a FS expert so this may not be
    a complete answer, but please consider it a start:

    - The FS should be block-device-based (e.g. a ram-based FS
    such as tmpfs should not enable cleancache)

    - To ensure coherency/correctness, the FS must ensure that all
    file removal or truncation operations either go through VFS
    or add hooks to do the equivalent "flush" operations (e.g.
    I started looking at FS-cache-based net FS's and was concerned
    there might be problems, dunno for sure)

    - To ensure coherency/correctness, inode numbers must be unique
    (e.g. no emulating 64-bit inode space on 32-bit inode numbers)

    - The FS must call the VFS superblock alloc and deactivate routines
    or add hooks to do the equivalent cleancache calls done there.

    - To maximize performance, all pages fetched from the FS should
    go through the do_mpage_readpage routine or the FS should add
    hooks to do the equivalent (e.g. btrfs requires a hook for this)

    - Currently, the FS blocksize must be the same as PAGESIZE. This
    is not an architectural restriction, but no backends currently
    support anything different (e.g. hugetlbfs? should not enable

    - A clustered FS should invoke the "shared_init_fs" cleancache
    hook to get best performance for some backends.

    Does that help?


     \ /
      Last update: 2010-08-03 19:41    [W:0.025 / U:57.944 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site