Date: Mon, 16 Dec 1996 12:05:06 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: pgiffuni@fps.biblos.unal.edu.co (Pedro Giffuni S.) Cc: terry@lambert.org, hackers@freebsd.org, fs@freebsd.org Subject: Re: Other filesystems under FreeBSD Message-ID: <199612161905.MAA01753@phaeton.artisoft.com> In-Reply-To: <32B4CCDA.D64@fps.biblos.unal.edu.co> from "Pedro Giffuni S." at Dec 15, 96 08:15:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> My interest in HPFS was due to WinNT=B4s support for that filesystem > (Microsoft also has his hands dirty on that): I am not interested in > NTFS, so the decent option seemed HPFS. Both MS and IBM agree that HPFS > is better than FAT, but only OS2 can format HPFS, which makes it almost > useless. > Perhaps before killing by system I should play to convert our FAT to > VFAT , that way I=B4ll learn more in the process (and erase win95). Note: as I said previously, NT 4.x drops support for HPFS; therefore you will not find it useful if your intent was to run it under NT after 3.51. As far as converting FAT to VFAT, Robert Nordier has already been doing this (done it?). The problem on VFAT is that the algortihm used for generating the short names depends on being able to look up in the second name space independently of the first while holding the lock on the entilre directory so other processes don't change it. Currently, the structure of the namei/lookup interface in FreeBSD is such that FS is expected to free resources allocated at the system call (FS consumer) layer... the nameidata buffer. I have a set of patches that apply against an older-that-current kernel that fix this problem, but the lookups are still not capable of supporting multiple name spaces without additional work. The full VFAT support and Windows 95/NT interoperability problem is non-trivial to solve. There is also the question of case insensitivity on lookup and case sensitivity on storage. I believe a proper implementation would have to take this into account, since the "long names" of "Foo" and "foo" will cause only the first to be found if you remount it under Win95 or WinNT. Probably the correct way to do this is to put a name space switch into the FS itself. In any case, when you lookup "foo" for the create, it needs to return "Foo" as a matching name so that you don't get the collision when you run NT/95. This is somewhat problematic for BSD (or Linux) because of the getdents interface (which ends up being the VOP_READDIR interface), which only holds on a directory block at a time. There is a semantic fix (needed to get rid of the lookup cookies for NFS, actually) which would also partially alleviate this problem. I say partially because globbing in BSD is done in user space, not in the kernel... quite wasteful, really, since it means pushing large amounts of non-matching data over the user/kernel boundry 8-(. One block at a time won't work because two creates could occur in seperate blocks based on the first create having a longer name and traversing further into the directory, while a second create might be able to occur in a block that was passed by the first, but which is large enough for the shorter second name. This is a problem because the collision resoloution on short names means that if the lookup operation does not contain both the short and the long name on lookup, a long name could hash to a short name, and a second create with a "long name" that was the same value as the hash result for the short name, would collide (ie: "VERYLONGNAME.TXT" and the hash value "VERYLO~1.TXT"). Clearly, if process 1 creates the long file name "VERYLONGNAME.TXT" and process 2 creates the long file "VERYLO~1.TXT", if they are created at the right time, there would be a lookup race (both in the system call code, the "vncalls" layer, and the NFS server code -- both of which are VFS clients). In any case, this is more of a problem only when you want to expose the multiple name spaces outside the kernel (which you *do* want, if, for instance, you are running a SAMBA server or NetWare server on your FreeBSD box). Otherwise, you never export the short name space, and internally lock the directory against reentrancy (bah!). A generic soloution to this would require fixing stacking so that you could attribute regular FFS files with additional "short names" using a stacking layer, instead of hacking up the FFS directory structure (I've done both for commercial software I've worked on; it's a performance/elegance trade off that is better made on the side of elegance everywhere but as a plug-in FS on a Microsoft OS). 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?199612161905.MAA01753>