Re: UFS not 64-bit clean?
Re: UFS not 64-bit clean?
- Subject: Re: UFS not 64-bit clean?
- From: Umesh Vaishampayan <email@hidden>
- Date: Tue, 11 Dec 2001 17:48:51 -0800
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