From owner-freebsd-fs Sun Dec 15 17:18:27 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA26329 for fs-outgoing; Sun, 15 Dec 1996 17:18:27 -0800 (PST) Received: from apolo.biblos.unal.edu.co ([168.176.37.75]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA26309; Sun, 15 Dec 1996 17:18:20 -0800 (PST) Received: from unalmodem.usc.unal.edu.co ([168.176.3.47]) by apolo.biblos.unal.edu.co (8.8.2/8.8.2) with SMTP id UAA04911; Sun, 15 Dec 1996 20:19:11 -0500 (EST) Message-ID: <32B4CCDA.D64@fps.biblos.unal.edu.co> Date: Sun, 15 Dec 1996 20:15:22 -0800 From: "Pedro Giffuni S." Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Terry Lambert CC: hackers@freebsd.org, fs@freebsd.org Subject: Re: Other filesystems under FreeBSD References: <199612152211.PAA24071@phaeton.artisoft.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > > You also seem a bit confused about what I said, vs. what I meant. > This is probably my fault, so I'll clarify a bit. > Yes I was, thanks for clarifying. > > If you find you have specific questions on implementation that aren't > answered in the Heidemann thesis in the FICUS project directory on > ftp.cs.ucla.edu, or in the book "The Design and Implementation of the > 4.4BSD Operating System", then send me mail. If I don't already > have the answer archived, I will find one for you (the SCO FS's are > rather important; HPFS has been dropped from BT 4.x and so is about > as important as OS/2: not very). > Thanks for the links, the only document I had was the thesis used to implement SYSV under Linux. Paul Monday said there it was easy to implement due to Linuxīs FS structure, so I (incorrectly) assumed Linux was better. My interest in HPFS was due to WinNTīs 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īll learn more in the process (and erase win95). best regards, Pedro. > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. From owner-freebsd-fs Mon Dec 16 10:49:34 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA24069 for fs-outgoing; Mon, 16 Dec 1996 10:49:34 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA24056 for ; Mon, 16 Dec 1996 10:49:28 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.4/8.8.2) id TAA25197; Mon, 16 Dec 1996 19:46:53 +0100 (MET) From: Guido van Rooij Message-Id: <199612161846.TAA25197@gvr.win.tue.nl> Subject: Re: Flash File System In-Reply-To: <32B25BA2.4CEC@fps.biblos.unal.edu.co> from "Pedro Giffuni S." at "Dec 13, 96 11:47:46 pm" To: pgiffuni@fps.biblos.unal.edu.co (Pedro Giffuni S.) Date: Mon, 16 Dec 1996 19:46:53 +0100 (MET) Cc: fs@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Pedro Giffuni S. wrote: > Hi, > While I continue to look which parts of the MSDN are freely > distributable some of you may find useful the Specification for MSīs > Flash File System, now available in: > ftp://freefall.freebsd.org/pub/incoming/msffs.ps.gz > Nothing there... -Guido From owner-freebsd-fs Mon Dec 16 11:08:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA25154 for fs-outgoing; Mon, 16 Dec 1996 11:08:21 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA25149; Mon, 16 Dec 1996 11:08:19 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA01753; Mon, 16 Dec 1996 12:05:06 -0700 From: Terry Lambert Message-Id: <199612161905.MAA01753@phaeton.artisoft.com> Subject: Re: Other filesystems under FreeBSD To: pgiffuni@fps.biblos.unal.edu.co (Pedro Giffuni S.) Date: Mon, 16 Dec 1996 12:05:06 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org, fs@freebsd.org In-Reply-To: <32B4CCDA.D64@fps.biblos.unal.edu.co> from "Pedro Giffuni S." at Dec 15, 96 08:15:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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. From owner-freebsd-fs Mon Dec 16 12:10:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA29131 for fs-outgoing; Mon, 16 Dec 1996 12:10:42 -0800 (PST) Received: from apolo.biblos.unal.edu.co ([168.176.37.75]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA29108; Mon, 16 Dec 1996 12:10:21 -0800 (PST) Received: from unalmodem.usc.unal.edu.co ([168.176.3.45]) by apolo.biblos.unal.edu.co (8.8.2/8.8.2) with SMTP id PAA11552; Mon, 16 Dec 1996 15:09:07 -0500 (EST) Message-ID: <32B5D5B4.5379@fps.biblos.unal.edu.co> Date: Mon, 16 Dec 1996 15:05:25 -0800 From: "Pedro Giffuni S." Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Guido van Rooij CC: fs@freebsd.org, hackers@freebsd.org Subject: Re: Flash File System References: <199612161846.TAA25197@gvr.win.tue.nl> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Guido van Rooij wrote: > > Pedro Giffuni S. wrote: > > Hi, > > While I continue to look which parts of the MSDN are freely > > distributable some of you may find useful the Specification for MSīs > > Flash File System, now available in: > > ftp://freefall.freebsd.org/pub/incoming/msffs.ps.gz > > > > Nothing there... > > -Guido Evidently that directory was cleaned, if some else needs the MS Flash System Specification, or the PnP Specification, just email me where to drop it. My network is becoming intermittent and I canīt grant anything, but weīll see. Pedro.