[svlug] Maxtor - Crapstor

Rick Moen rick at linuxmafia.com
Tue Mar 6 19:55:02 PST 2001

begin  paul quotation:

> The stated reason in the article is:
> "FreeBSD did not support large file sizes, Macintosh and newer Novell
> file systems, or backup and management software from companies such as
> OpenView, Tivoli and Microsoft, Wilkins said."
> How valid that is, I don't know since it's items I don't use or care
> about (other than large files).

Curing the 2GB file-size limit in any 32-bit Unix (32-bit integers for
file-descriptors and locking, implying a limit of 2 ^ 31 - 1 = 2GB) 
requires implementing the Large File Summit extensions, drafted at an
X/Open meeting in '96 (http://ftp.sas.com/standards/large.file/).  That
requires support in the kernel's header files, the libc (which must be
compiled against those aforementioned header files), and the kernel's
filesystem drivers.  And then you have to re-write and recompile apps to 
support the new calls.

FFS and UFS do not (yet) support LFS extensions, to my knowledge.  On 
Linux, given drivers from kernel 2.4.0test7 or later (or 2.2.x with
LFS patches) the drivers for ext2, ext3, ReiserFS (3.6.x and up), IBM
JFS, SGI XFS, and really recent NFSv3 client code over one of the
foregoing can reportedly support LFS.  Probably not yet FreeBSD's drivers. 

And, on Linux, you'd need specifically glibc 2.2 for proper LFS.  Which
would require braver souls than me.

But of course if you were doing a dedicated file store, the logical
remedy might be to back-end it into some sort of database storage.

Cheers,             We write precisely            We say exactly
Rick Moen           Since such is our habit in    How to do a thing or how
rick at linuxmafia.com Talking to machines;          Every detail works.
Excerpt from Prof. Touretzky's decss-haiku.txt @ http://www.cs.cmu.edu/~dst/

More information about the svlug mailing list