Date: Sun, 8 Oct 1995 15:22:38 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: henrich@crh.cl.msu.edu (Charles Henrich) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 52gb RAID, works, sorta. Message-ID: <199510082222.PAA07308@phaeton.artisoft.com> In-Reply-To: <199510070515.BAA06854@crh.cl.msu.edu> from "Charles Henrich" at Oct 7, 95 01:15:23 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I was able to get FreeBSD not to panic, by going into DOS and fdisking > the RAID array. After that I was able to boot FreeBSD and lay down a > disklabel and new parition table. I created a single 52GB partition > on the array, newfs took 6 hours to complete, When it was done it > appeared to work, however DF reports some strange numbers, I've added > some more debug: > > /dev/sd0s1c 51677350 106 4593383 0% /mnt > > f_blocks: 51677350 > f_bfree: 51677244 > f_bavail: 4593383 > f_bsize: 1024 > > What is with the huge discrepence between bfree and bavail? If im > reading this right my 52gb partition gives me 4gb of data space?! There is an explicit limitation on file size because of the paging code. This is enforced in the "get limits" stuff in the ufs/ffs/lfs code. There is also a limit on the addressable blocks because of some issues in about 6 places. Correcting these issues would take some work with a large drive in place to let you interactively see from whence the problems derive. One is a sign extension problem across a quad. When this is resolved, the limit goes up from 4G to 8G. Unfortunately, I don't have a 9G drive, or even a larger than 4G drive with which to validate the first change, let alone track down the others. This would be a worthwhile pursuit, but it would take someone with a large disk (like you have) to catch all the potential problems. Even then, there are issues that will probably only show on regression testing. The file size limitation, being VM related, will require the ability to place one or more VM windows onto a file (VM based I/O effectively memory maps all file I/O). I don't see this being resolved unledd you option out vmio entirely (and thus reintroduce the bugs that were never corrected in the 4.4BSD code nor NetBSD code, especially with regard to write clustering) or set up a vectored mapping table per vnode so that multiple mappings can be maintained by "segment descriptor". Even with virtual segment mode on the processor to get huge page sizes, there is still a 32 bit limit on the file size without some type of windowed access. You'd have to check with David or John for the exact window limit in the current code (it was less than 32 bits the last time I saw them post about it). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510082222.PAA07308>