On Tuesday, December 11, 2001, at 03:55 PM, Chris Bednar wrote: On Tue, 11 Dec 2001, Umesh Vaishampayan wrote: On Tuesday, December 11, 2001, at 10:31 AM, Chris Bednar wrote: I'm fooling with using UFS, and I notice that I get in trouble at the 4-gig limit. That's artificial limitation put in UFS few years ago when I implemented UBC. At that time the VM did not support 64 bit data paths. Hence anything above 4GB was not accessible. [Well, you could try to access it, but the offset would wrap and lead to interesting :-) data corruption]. Hence the following code was added: Thanks for the clear answer! (and thanks to Louis for his, too) I feel better and better about this OS... I might even try building a kernel. Good! Now that VM supports 64 bit data paths, the code above can be removed. But will it work... well, I went through this with Linux; maybe I'll try it again. Yes it will. The VM paths are well tested using HFS+. And UFS paths are tested in Rhapsody^W Mac OS X Server 1.0 and in early xnu. So I have reason to believe that "it should just work". Is the darwin UFS implementation not 64-bit clean? Yes it is. Well, it is, in the sense that it won't (necessarily) crash if there's a file over 4GB on the platter, but truncating the file size this way doesn't seem all that clean to me... If there is an existing file over 4GB, NO, we do not truncate silently. stat() should still return the size to you. bsd/ufs/ufs/ufs_vnops.c: 321 int 322 ufs_getattr(ap) 323 struct vop_getattr_args /* { 324 struct vnode *a_vp; 325 struct vattr *a_vap; 326 struct ucred *a_cred; 327 struct proc *a_p; 328 } */ *ap; 329 { 330 register struct vnode *vp = ap->a_vp; /* ... */ 346 vap->va_size = ip->i_din.di_size; What the artificial limit does is, it does not let you grow the file beyond the limit. It also prevents you from reading the file past 4GB. bsd/ufs/ffs/ffs_inode.c: 174 /* 175 * Truncate the inode oip to at most length size, freeing the 176 * disk blocks. 177 */ 178 ffs_truncate(ap) 179 struct vop_truncate_args /* { 180 struct vnode *a_vp; 181 off_t a_length; 182 int a_flags; 183 struct ucred *a_cred; 184 struct proc *a_p; 185 } */ *ap; 186 { 187 register struct vnode *ovp = ap->a_vp; /* ... */ 209 if (length > fs->fs_maxfilesize) 210 return (EFBIG); 211 bsd/ufs/ufs/ufs_readwrite.c: 70 ffs_read(ap) 71 struct vop_read_args /* { 72 struct vnode *a_vp; 73 struct uio *a_uio; 74 int a_ioflag; 75 struct ucred *a_cred; 76 } */ *ap; 77 { 78 register struct vnode *vp; /* ... */ 115 if (uio->uio_offset > fs->fs_maxfilesize) 116 return (EFBIG); 117 /* ... */ 198 ffs_write(ap) 199 struct vop_write_args /* { 200 struct vnode *a_vp; 201 struct uio *a_uio; 202 int a_ioflag; 203 struct ucred *a_cred; 204 } */ *ap; 205 { 206 register struct vnode *vp; /* ... */ 255 if (uio->uio_offset < 0 || 256 (u_int64_t)uio->uio_offset + uio->uio_resid > fs->fs_maxfilesize ) 257 return (EFBIG); I am not sure who is dropping the EFBIG on the floor... Any way, with a kernel with the fix for 2660080, you should be able to read that file of yours just fine. --Umesh -- Umesh Vaishampayan Apple Computer, Inc. Mac OS X Kernel Ph: (408) 974 0229