Re: UFS not 64-bit clean?
Re: UFS not 64-bit clean?
- Subject: Re: UFS not 64-bit clean?
- From: Chris Bednar <email@hidden>
- Date: Tue, 11 Dec 2001 13:34:58 -0600 (CST)
>
Depends on what you mean. It works correctly for me, at least somewhere
>
between 7 and 8 gigs. It does not, however, appear to support files that
>
are >4 gigs in size, at least on 32 bit machines.
That's what I mean (files > 4G). FreeBSD's UFS gets past
the 4G limit on 32-bit platforms, for example, and of course
Linux works fine that way with several filesystems on at least
x86 and ppc these days.
HFS+ and NFSv3 work fine on OSX too, as far as I can tell.
I glanced through the kernel code, and I see that LFS
support is possibly there, although it may require a
`#define LFS 1' kinda thing somewhere (a kernel-config
option?)
I went through all this with Linux back when I had time
to fool with things like arch/ppc/kernel/misc.S, but I'm hoping
to keep myself kinda clueless about building xnu as long as
I can ;)
>
Just for grins, though, I tried concatenating to the end of a 4 gig file.
>
The append fails -silently-. AIEEEEE! Filing a bug.
Well, yes, that's really cute, too; I did something
like `rsh zorak cat RedHat7.2.iso > RedHat7.2.iso` and
it ran without complaint, but the file looked to be truncated
at 4G.
>
> 1) local
>
> 2) case sensitive
>
> 3) LFS-ready
>
>
>
I don't think you'd get much disagreement anyway. Keep in mind, this
>
tends to be a UNIX-y crowd. :-) I'm unclear why 64 bit file offsets are
>
a requirement for this, though... or were you just wondering about disks
>
over 4 gigs?
The three are more or less unrelated, except that I'd like
to have them together in one FS on OSX. As to disagreement,
I suppose the kernel list may be safe, but darwinos-users
is full of a big linguistic argument at the moment...
----
Chris J. Bednar
Director, Distributed Computing Product Group
http://AdvancedDataSolutions.com/