On Thu, Aug 03, 2006 at 12:17:41AM -0700, Andrew Morton wrote:
> - running igrab() in the writepage() path is really going to hammer
> inode_lock. Something else will need to be done here.
> - Running iput() in entd() is a bit surprising. iirc there are various ways
> in which this can recur into the filesystem, perform I/O, etc. I guess it
> works..
>
> But again, it will hammer inode_lock.
XFS used to do this and it caused lots of problems. What xfs does now
is to keep an iocount in the inode for outstanding I/Os and ->clear_inode
waits for that I/O to finish using hashed waitqueues. It would be nice
to have a facility like that in generic code.
> - reiser4_readpages() shouldn't need to clean up the remaining pages on
> *pages. read_cache_pages() does that now.
Without looking at the code I remember someone from the Namesys people told
me they could use plain mpage_readpages now. Anything still blocking using
that function?
> - General comment: the lack of support for extended attributes, access
> control lists and direct-io is a big problem and it's getting bigger. I
> don't see how a vendor could support reiser4 without these features and
> permanent lack of vendor support will hurt.
>
> What's the plan here?
Another issue is the lack of support for blocksize < pagesize. This prevents
it from beeing used across architectures. Even worse when I tried the last
time it didn't allow me to create a 64k blocksize filesystem that I could
actually test on ppc64.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
