Messages in this thread |  | | Date | Fri, 06 Sep 2002 10:08:47 +0100 | From | Anton Altaparmakov <> | Subject | Re: (fwd) Re: [RFC] mount flag "direct" |
| |
At 09:57 06/09/02, Peter T. Breuer wrote: >"Anton Altaparmakov wrote:" > > [DanP] > > >He was going to go hack the vfs, so in his mind, practical issues of > how the > > >vfs works now aren't an obstacle. The only mistake he's making is > seriously > > >underestimating how much effort is required to learn enough to do this > kind > > >of surgery and have a remote chance that the patient will survive. > > > > Ok so he plans to rewrite the whole I/O subsystem starting from block > up to > > FS drivers and VFS. Great. See him again in 10 years... And his changes > >I've had a look now. I concur that e2fs at least is full of assumptions >that it has various different sorts of metadata in memory at all times. >I can't rewrite that, or even add a "warning will robinson" callback to >vfs, as I intended. What I can do, I think, is ..
Oh, you saw the light. (-: I can assure you that most file systems make such assumptions. Certainly NTFS does... I designed the driver all around caching metadata to optimize access to actual data. Once I enable direct_IO, I plan to keep all metadata caching in place, just stop caching the actual file data. That should give maximum performance I think.
>.. simply do a dput of the fs root directory from time to time, from >vfs - whenever I think it is appropriate. As far as I can see from my >quick look that may cause the dcache path off that to be GC'ed. And >that may be enough to do a few experiments for O_DIRDIRECT.
What does "GC" mean?
Anton
-- "I've not lost my mind. It's backed up on tape somewhere." - Unknown -- Anton Altaparmakov <aia21 at cantab.net> (replace at with @) Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
- 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/
|  |