Date: Tue, 12 Nov 1996 14:02:02 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: mark@quickweb.com (Mark Mayo) Cc: terry@lambert.org, gibbs@freefall.freebsd.org, roberto@keltia.freenix.fr, freebsd-current@FreeBSD.org Subject: Re: ufs is too slow? Message-ID: <199611122102.OAA20928@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.94.961112135927.17280A-100000@vinyl.quickweb.com> from "Mark Mayo" at Nov 12, 96 02:12:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I just checked, and all they mention in the press_release is that they > will be using the Veritas Volume Manger - I don't kow if this > _necessarily_ implies use of the Veritas File sSystem. And when you look > at it, all the veritas file system does above and beyond a NTFS is the > ability to 'Live" manage volumes. Please correct me if I'm wrong. They > even talk about the performance increases through the use of 'extents" - > the same terminology is used to decribe NTFS. To me, they really don't > seem that different, and they mention an upgrade procut to be released in > mid 1997 for existing NT 4.0 servers -- all this leads me to believe that > they might be implementing the volume manager on exisiting NTFS > filesystems. The file manager will supposedly work with FS's other than VXFS, though they were unable to make it work in NetWare, last I heard. I had heard specifically that VXFS would be ported. The "volume manager" product is generally nothing more than "value add" for their VXFS, so I suspect that's still what they are talking about. The Veritas press release made it look like VXFS will be the native FS for NT in the first paragraph... however, they go on to hem, haw, and hedge about their technology being "value add" and about retrofitting their stuff into NT 4.x. From this I suspect the real story is that they are simply value add, and what they got from their deal is the documentation that Microsoft has been promising everyone else for about a year and a half now (ever since they released the sample CDFS code to the developers back when NT 3.5 was beta...). > All that said, do you think it's worth my time to try and implement NTFS > support under FreBSD? Probably. It's at least as valuable as MSDOS, VFAT, HPFS, or EXT2FS support. Any alient FS is a good bet when you are trying to position yourself as an interoperability bridge (FreeBSD's prime strength right now). > I was thinking of trying to get the existing Linux > code ruuing, and adding the ability for it to read the 8.3 short file > names, but under writeds only write out the long Unicode file name to > increase performance. I agree with Terry that NTFS could be significantly > faster on a non backwords compatible non-microsoft implementation. > > Thoughts? The Linux code does not support writing, mostly because their VFS layer is badly abstracted for orthogonal access necessary to support log rollback. FreeBSD actually has similar layering problems, but they are closer to being fixable (less code required than the Linux VFS code). Neither OS supports the idea of multiple name spaces very well. The default NTFS name space is Unicode. The short name support is handled by attributing the files. I believe NTFS was not supported in Win95 because of the old "search continue" having to have a cookie that is valid for an indefinite future time. There was code in the Win95 IFS in the Beta that was taken out in the release that handled the backward compatability interfaces automatically by mapping an LRU cookie list (similar to the *crap* FreeBSD supports for NFS dirent formatting) in there. They removed it because they apparently had an insertion bug and couldn't find it. They hacked the code back in at the VFAT layer, and changed the IFS consumer requirements so that they no longer matched the IFS documentation shipped with the Win95 SDK. I know this because I spent several weeks in WinICE on both versions of the IFSMGR.VXD. I believe that FreeBSD would suffer some serious problems handling short name generation because of this, and this would, in turn, cause problems for programs running in DOS windows on NT when operating against NTFS file names generated by FreeBSD. Specifically, there would be crashes which were simply not recoverable. I have to note at this point that, since names must be handled twice in a conforming-to-MS-expectations-about-name-space implementation, any gains for going to a btree directory layout are probably lost *immediately* on the second inode access for the short name attribute. The soloution is to support multiple name space collision resoloution at the namei layer for a CREATE nameiop. This requires two full directory traversals, the first one locked, for the short name creation. I did this code once already when I ported the long/short name support into FFS for Artisofts FFS port to Win95. This happens to be *exactly* how Win95 deals with name resoloution (using the IFS functions CreateBasis/MatchBasisName/AppendBasisTail) for the same effect, and for the same reasons. The only way to safely correct this is to make the component name handling opaque to the underlying FS. This was the substance of my changes to the namei/VOP_LOOKUP layering when I created the nameifree() and supplied all those patches everyone hated. By moving the buffer free to the layer in which the buffer allocate originated, the interface was made orthogonal, and it was possible to slip in a second iteration of the directory for the short name collision check (which has to be done at this level to assure that multiple client creates do not cause a creation race which results in a duplicate short name). I think that to get past "ready-only" for an NTFS, you will have to readdress these issues. Unfortunately, current keeps changing slightly, and the Lite2 integration has not happened, so my patches are out of date unless you are running my full source base (which is out of date for VM and a couple of other serious subsystems). 8-(. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611122102.OAA20928>