[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c773d65b-e107-428c-ba6f-04d4ca9f8361@default>
Date: Wed, 9 Jun 2010 20:28:21 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@...cle.com>
To: ngupta@...are.org
Cc: chris.mason@...cle.com, viro@...iv.linux.org.uk,
akpm@...ux-foundation.org, adilger@....com, tytso@....edu,
mfasheh@...e.com, joel.becker@...cle.com, matthew@....cx,
linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
ocfs2-devel@....oracle.com, linux-mm@...ck.org, jeremy@...p.org,
JBeulich@...ell.com, kurt.hackel@...cle.com, npiggin@...e.de,
dave.mccracken@...cle.com, riel@...hat.com, avi@...hat.com,
konrad.wilk@...cle.com
Subject: RE: [PATCH V2 2/7] Cleancache (was Transcendent Memory): core files
> I just finished a rough (but working) implementation of in-kernel
> page cache compression backend (called zcache). During this work,
> I found some issues with cleancache, mostly related to (lack of)
> comments/documentation:
Great to hear! And excellent feedback on the missing
documentation... I am working on this right now so your
feedback is very timely.
(documentation and funcition return values comments deleted
as I will fix all of them)
> > +
> > +static inline int cleancache_init_fs(size_t pagesize)
> > +
>
> - It seems that returning pool_id of 0 is considered as error
> condition (as it appears from deactivate_locked_super() changes).
> This seems weird; I think only negative pool_id should considered
> as error. Anyway, please add function comments for these.
Hmmm... this is a bug. 0 is a valid pool_id. I'll fix it
for the next rev.
> Page cache compression was a long-pending project. I'm glad its
> coming into shape with the help of cleancache :)
Thanks!
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists