Messages in this thread | | | Subject | Re: reiser4: maybe just fix bugs? | From | "Vladimir V. Saveliev" <> | Date | Tue, 01 Aug 2006 15:24:37 +0400 |
| |
Hello
On Mon, 2006-07-31 at 20:18 -0600, Hans Reiser wrote: > Andrew Morton wrote:
> >The writeout code is ugly, although that's largely due to a mismatch between > >what reiser4 wants to do and what the VFS/MM expects it to do.
Yes. reiser4 writeouts atoms. Most of pages get into atoms via sys_write. But pages dirtied via shared mapping do not. They get into atoms in reiser4's writepages address space operation. That is why reiser4_sync_inodes has two steps: on first one it calls generic_sync_sb_inodes to call writepages for dirty inodes to capture pages dirtied via shared mapping into atoms. Second step flushes atoms.
> > > I agree --- both with it being ugly, and that being part of why. > > > If it > >works, we can live with it, although perhaps the VFS could be made smarter. > > > > > I would be curious regarding any ideas on that. Next time I read > through that code, I will keep in mind that you are open to making VFS > changes if it improves things, and I will try to get clever somehow and > send it by you. Our squalloc code though is I must say the most > complicated and ugliest piece of code I ever worked on for which every > cumulative ugliness had a substantive performance advantage requiring us > to keep it. If you spare yourself from reading that, it is > understandable to do so. > > >I'd say that resier4's major problem is the lack of xattrs, acls and > >direct-io. That's likely to significantly limit its vendor uptake.
xattrs is really a problem.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |