Date: Fri, 15 Mar 2002 14:09:06 -0600 From: "Matthew Rezny" <mrezny@umr.edu> To: "Paul Schenkeveld" <fb-fs@psconsult.nl> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: disks > 1TB Message-ID: <20020315200812.A945C37B400@hub.freebsd.org> In-Reply-To: <20020315104815.A79816@psconsult.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
I haven't tried that. I think I need to clarify my points. 1) disklabel has a limit on how large a volume it can handle because it uses a signed variable to temporarily store a value that ultimately goes into an unsigned storage location. I see this as something that should be fixed in the source tree since its a change to one line of code to remove an annoyance that more people will soon run into given the increases in cheap storage. 2) The rest of the OS has similar problems using signed where unneeded which limits addressable disk space to 1TB. This is something that will begin to be a problem and need to be worked on. The quick fix is switch all to unsigned and raise the limit to 2TB. The long term solution is change it all to 64bit, but that changes the size of everything stored and so that change would take a lot more work to ensure that doesn't cause problems with alignment and storage. On Fri, 15 Mar 2002 10:48:16 +0100, Paul Schenkeveld wrote: >On Fri, Mar 15, 2002 at 02:35:31AM -0600, Matthew Rezny wrote: >> I just bought a 3ware 7810 controller and 8 160GB drives, which in >> RAID5 yields 1.04TB (real TB). Having previously seen statements that >> FFS limit is 64TB, I expected this to work. Unfortunately I found that >> the number of sectors becomes an issue. Looking through the mailing >> list history I see this has come up before and it will take a lot to >> solve, more than the spare time I have this weekend. The quick solution >> is make a 1TB filesystem and let the extra .04TB go to waste rather >> than try to patch the whole system. However, there is a slight problem >> with this, which is limits in the disklabel tool. The disklabel >> structure which is stored on disk uses u_int32_t for the number of >> sectors in the device. The disklabel tool uses int when interpretting >> all numbers in the getasciilabel() function. This limits disklabel to >> 1TB devices. If the declaration on line 964 of disklabel.c is changed >> from "int v" to "u_int32_t v" then this limit is lifted. This change is >> safe since the actual value on disk is unsigned. Using unsigned in the >> input allow disklabel to work with devices up to 2TB. This allows >> creation of 1TB slices on devices >1TB so that at least part can be >> used in the meantime while we wait for the limit to be lifted elsewhere >> in the system. > >Did you try to divide the disk in two FreeBSD slices using fdisk? >The numbers in disklabel are relative to the fdisk slice so your >xx0s1c partition is the same size as the fdisk slice. > >> Also, I've seen one mention of 4TB systems in the mailing list >> archives. How was this done? Kernel patches, other trickery? > >-- >Paul Schenkeveld, Consultant >PSconsult ICT Services BV To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020315200812.A945C37B400>