|
From: Anton A. <ai...@ca...> - 2001-07-03 16:02:48
|
Hello all, Flatcap (Richard) and I have decided it's about time we started using the mailing list for NTFS discussions instead of messaging each other by ICQ. Here is a quick summary of previous discussion about NTFS driver TNG module you might have noticed in CVS (currently mostly empty), it clarifies what TNG is and what the plans for development are. - Just thought people might be interested: Anton (a while ago): "TNG = the next generation. seems to be a commonly used abbreviation for starting something from scratch. - So it's for a new driver code base. - I started it a while ago but it is now terribly out of date so I have to update it before I can commit it. This will be the everything in page cache all singing and dancing driver one day in the future." Anton (last night): "I am starting to get thoroughly fed up with trying to fix the current driver. So much is not implemented and what is implemented has bugs all over the write code paths as I am finding out slowly and/or is so different from how I would like to have it that I am starting to seriously consider ditching the existing driver and starting on TNG. Or at the very least throwing out the write support altogether. It is very messed up. Just fixing cluster allocation took me almost half a week when it would have taken half an hour to write from scratch given the correct framework... I will think about it some more and will have a close look at the page cache over the weekend. I am gaining a better understanding of it slowly and I have somewhat of an idea of how to use it for NTFS (it's not going to be pretty but it should fly speedwise and I hope to be able to hide the nastiness within the NTFS address_space_operations, so the rest of the driver will be clean [I wish...])." Flatcap: "Before I saw the 'TNG' dir, I thought of putting together a skeleton driver, just stubs of code. Something upon which we could write a driver." Anton: "The general idea is to write a read-only driver which will use the page cache and several slab caches for storage of structures but at the same time all SMP locking needed for writing is put in place. So to enable writing we can just add more functions, hopefully having done a good enough job of the reading and locking, so that then existing read code needs not be modified. Writing would then only happen into memory (page cache, slab cache, etc) in the normal code and writing to disk will only happen through kntfsd running as a kernel thread. When necessary we can force-wakeup kntfsd, possibly telling it somehow that something specific needs writing to disk. But I want to try and keep writing to device localized to kntfsd and nowhere else so that we have better control over whether writing is enabled or not. This will be extremely important for transactional writing and the log file system should we ever manage to implement it... - Once I have cleaned up TNG I will commit it. It will be pretty much a skeleton driver as I plan to ditch most of the stuff that is in it at the moment..." Flatcap: "OK the logfile stuff may (always) be beyond our control, but there are very good reasons for transaction stuff. I have a plan too!" Anton: "Re: transaction stuff Indeed. the simplest being that you can back trace to leave in a consistent state on error. (e.g. if in the middle of extending a file we fail, we want the file to return to it's state before the error rather than leaving a corrupt file on disk...)" That's where we left off last night (note that this is a summary only)... Anton -- "Nothing succeeds like success." - Alexandre Dumas -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ |
