December 2001 - Darwin-kernel

Re: UFS not 64-bit clean?
by Chris Bednar 11 Dec '01

11 Dec '01

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. > bsd/ufs/ffs/ffs_vfsops.c: Yep, I had just found that. > 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. > > 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... > > 3) LFS-ready > > That you do not get without doing LOTS of work on it first... Oh, don't be silly! There are only 15,364 lines of code in bsd/ufs/* , and that includes comments! how much work could it be ;) ---- Chris J. Bednar Director, Distributed Computing Product Group http://AdvancedDataSolutions.com/

1 0

Re: UFS not 64-bit clean?
by David A. Gatwood 11 Dec '01

11 Dec '01

On Tue, 11 Dec 2001, Umesh Vaishampayan wrote: > Now that VM supports 64 bit data paths, the code above can be removed. > > Radar #2660080: UFS limits a file to 4GB > was filed to track this issue. Can fs_maxfilesize ever be less than the file system size besides this particular case? If so, then the second bug is still an issue. The second bug is this: 1. upon reaching fs_maxfilesize bytes, somewhere in either the kernel or libc, the error return is getting lost, and the process is getting a return value of success(0) for the fputs call, rather than EOF (-1) to indicate an error. 2. errno is not getting set correctly. It should be EFBIG (27), but instead it is 0. This is probably caused by #1. Later, David --------------------------------------------------------------------- Check out my weekly web comic: http://www.techmagazine.org

1 0

Re: UFS not 64-bit clean?
by Louis Gerbarg 11 Dec '01

11 Dec '01

On Tuesday, December 11, 2001, at 02:19 PM, Chris Bednar wrote: 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 ;) As with all of the widely available source code bases for kernels I have seen, it is not that bad to build, but it requires specific steps (some of which may or may not be well documented). Yup. Building, installing, keeping different versions on the same system, making sure modules are installed right... just not ready for the learning curve today. I'll try it after I get a good run of sleep. like `rsh zorak cat RedHat7.2.iso > RedHat7.2.iso` and it ran without complaint, but the file looked to be truncated at 4G. This is not about 64bit cleanliness (that really involves in memory structure and call alignment). The max file size on UFS is either 2 or 4 gigs. Really? Any UFS, or just Darwin's? All of this worked in FreeBSD. Am I confused, or is this really because the UFS code in Darwin is from the dim, ancient past? Just Darwin's. FreeBSD's FFS as a lot of improvements over ours. Whether ot not their kernel internal are 64bit clean is another matter, I believe they are as well though. Um, if you really want to try to build LFS you can be adding the line "option LFS" to the conf files in xnu. You really do not want to though. You are correct. I'm having a language problem; I mean ``Large File Summit''; all I mean by LFS is that file offsets are 64-bit, and I can have files bigger than 4G. The reason I used the expression ``64-bit clean'' is that I assumed that the situation was like that with pre-2.4 linux; on-disk structures were 64-bit, but the kernel code wasn't. I do see (xnu-9-1/bsd/ufs/ffs/ffs_vfsops.c:390, for example) that there's a check to see if the on-disk maxfilesize is greater than 4GB (in which case it's reset in memory to 4GB), and that on-disk number does appear to be 64 bits wide, as is, I think, the on-disk i_size... I do not have the exact details on this. You can try commenting out the override and see if it works, but it tends to be when we disable something we do it because it is broken (unlike some conspiracy theorists who think we disable features just to annoy our users ;-) Just so you know that LFS in our kernel is probably not referring to what you want it to. Louis

1 0

Re: UFS not 64-bit clean?
by Umesh Vaishampayan 11 Dec '01

11 Dec '01

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: bsd/ufs/ffs/ffs_vfsops.c: 483 /* 484 * Common code for mount and mountroot 485 */ 486 int 487 ffs_mountfs(devvp, mp, p) 488 register struct vnode *devvp; 489 struct mount *mp; 490 struct proc *p; 491 { 492 register struct ufsmount *ump; /* ... */ 732 maxfilesize = (u_int64_t)0x100000000; /* 4GB */ 733 #if 0 734 maxfilesize = (u_int64_t)0x40000000 * fs->fs_bsize - 1; /* XXX */ 735 #endif /* 0 */ 736 if (fs->fs_maxfilesize > maxfilesize) /* XXX */ 737 fs->fs_maxfilesize = maxfilesize; /* XXX */ Now that VM supports 64 bit data paths, the code above can be removed. Radar #2660080: UFS limits a file to 4GB was filed to track this issue. Is the darwin UFS implementation not 64-bit clean? Yes it is. Thankfully, I don't have this trouble with NFS or HFS+, but I'm trying to have a FS that's 1) local 2) case sensitive You get both with UFS. 3) LFS-ready That you do not get without doing LOTS of work on it first... --Umesh -- Umesh Vaishampayan Apple Computer, Inc. Mac OS X Kernel Ph: (408) 974 0229

1 0

Re: UFS not 64-bit clean?
by Chris Bednar 11 Dec '01

11 Dec '01

> > 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 ;) > > As with all of the widely available source code bases for kernels I have > seen, it is not that bad to build, but it requires specific steps (some > of which may or may not be well documented). Yup. Building, installing, keeping different versions on the same system, making sure modules are installed right... just not ready for the learning curve today. I'll try it after I get a good run of sleep. > > like `rsh zorak cat RedHat7.2.iso > RedHat7.2.iso` and > > it ran without complaint, but the file looked to be truncated > > at 4G. > > This is not about 64bit cleanliness (that really involves in memory > structure and call alignment). The max file size on UFS is either 2 or 4 > gigs. Really? Any UFS, or just Darwin's? All of this worked in FreeBSD. Am I confused, or is this really because the UFS code in Darwin is from the dim, ancient past? > Um, if you really want to try to build LFS you can be adding the line > "option LFS" to the conf files in xnu. You really do not want to though. You are correct. I'm having a language problem; I mean ``Large File Summit''; all I mean by LFS is that file offsets are 64-bit, and I can have files bigger than 4G. The reason I used the expression ``64-bit clean'' is that I assumed that the situation was like that with pre-2.4 linux; on-disk structures were 64-bit, but the kernel code wasn't. I do see (xnu-9-1/bsd/ufs/ffs/ffs_vfsops.c:390, for example) that there's a check to see if the on-disk maxfilesize is greater than 4GB (in which case it's reset in memory to 4GB), and that on-disk number does appear to be 64 bits wide, as is, I think, the on-disk i_size... ---- Chris J. Bednar Director, Distributed Computing Product Group http://AdvancedDataSolutions.com/

1 0

Re: UFS not 64-bit clean?
by Louis Gerbarg 11 Dec '01

11 Dec '01

On Tuesday, December 11, 2001, at 11:34 AM, Chris Bednar wrote: 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 ;) As with all of the widely available source code bases for kernels I have seen, it is not that bad to build, but it requires specific steps (some of which may or may not be well documented). 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. This is not about 64bit cleanliness (that really involves in memory structure and call alignment). The max file size on UFS is either 2 or 4 gigs. 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... Um, if you really want to try to build LFS you can be adding the line "option LFS" to the conf files in xnu. You really do not want to though. The LFS code is stale (and may not be complete any more). It is based on the old 4.4Lite LFS, which was not really production quality anyway (the NetBSD folks seem to have been working on it in recent years, but we never had that stuff). LFS probably has not been updated to UBC, may never have worked int he first place, and is missing hooks for things like the cleaner, which is not included in the standard source. In other words, how much pain do you feel like enduring.... Don't get me wrong. I love the concept of an LFS. I think it is very cool, and I think that in the future someone may do one that works well. But in the present they leave a lot to be desired, and what you see in our code is vestigial stuff from days long past. Louis

1 0

Re: UFS not 64-bit clean?
by Chris Bednar 11 Dec '01

11 Dec '01

> 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/

1 0

Re: UFS not 64-bit clean?
by David A. Gatwood 11 Dec '01

11 Dec '01

On Tue, 11 Dec 2001, Chris Bednar wrote: > I'm fooling with using UFS, and I notice that > I get in trouble at the 4-gig limit. Is the darwin > UFS implementation not 64-bit clean? 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. Just for grins, though, I tried concatenating to the end of a 4 gig file. The append fails -silently-. AIEEEEE! Filing a bug. > Thankfully, > I don't have this trouble with NFS or HFS+, but > I'm trying to have a FS that's > > 1) local > 2) case sensitive > 3) LFS-ready > > I'm not particularly interested in a discussion of > why I want (2); let's try not to repeat all of that > here :/ 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? Later, David --------------------------------------------------------------------- Check out my weekly web comic: http://www.techmagazine.org

1 0

UFS not 64-bit clean?
by Chris Bednar 11 Dec '01

11 Dec '01

I'm fooling with using UFS, and I notice that I get in trouble at the 4-gig limit. Is the darwin UFS implementation not 64-bit clean? Thankfully, I don't have this trouble with NFS or HFS+, but I'm trying to have a FS that's 1) local 2) case sensitive 3) LFS-ready I'm not particularly interested in a discussion of why I want (2); let's try not to repeat all of that here :/ thanks ---- Chris J. Bednar Director, Distributed Computing Product Group http://AdvancedDataSolutions.com/

1 0

Re(2): Heathrow interrupt weirdness
by Benjamin Herrenschmidt 11 Dec '01

11 Dec '01

On Mon, Dec 10, 2001, David A. Gatwood <dgatwood(a)gatwood.net> wrote: >On Mon, 10 Dec 2001, Benjamin Herrenschmidt wrote: > >> While looking at the Heathrow.cpp code to compare with what I'm doing >> in Linux (chasing a lost interrupt problem with the PMU that occurs >> occasionally), I found something weird in the Darwin implementation. > >Hey, Ben. At least it only occurs occasionally for you. In MkLinux, it's >relatively easy to trigger. :-| Well, it didn't happen until some additional changes I did to our interrupt management :( >My gut is telling me that continuing to trigger interrupts until the >status register is read could generate spurious interrupts that would >cause performance problems. After all, clearing the interrupt bit happens >in the interrupt context, but reading the status bit probably happens in a >kernel thread. Just my gut. Darwin does soft-disable, doesn't it ? Well, in linux we mask the interrupt on the controller when it is triggered and unmask it on exit from the handler. One of the changes I did recently to my code was for the main interrupt dispatch to loop until the lower layer (interrupt controller driver) didn't return any new interrupt to service. By doing so, I also removed the code to trigger a lost interrupt when re-enabling on the handler exit code path, since I know we well loop again reading for interrupts. I only trigger the lost interrupt when re-enabling an interrupt outside of this code path. Note that I still mark the interrupt as "lost" so it's properly caught by the new iteration, but I don't cause a new interrupt on the CPU (we use the DEC to trigger fake interrupts in this case). >Cough. Guess Darwin doesn't lose many interrupts or someone would have >noticed this. :-) Heh, I hope so ;) >I don't seem to have the Heathrow driver handy, but looking at the GC >driver (which should be very similar, I hope), it's being &ed with >kTypeLevelMask, which is a 32 bit quantity. How could that be non-zero? The Heathrow driver has 2 sets of registers, so interrupt vectors can range from 0 to 63. Code checking the type of interrupt by doing kTypeLevelMask & (1 & << vectorNumber) may lead to strange results if vectorNumber is > 31 (I'm not sure about what C standard says, but I know for sure many compilers loves to miscompile such a construct). Ben.

1 0