Re: Large (3TB) HDD support
* Peter Kay syllops...@syllopsium.co.uk [2012-06-04 21:00]: It seems to me it would be more sensible to stick a disklabel inside a new OpenBSD GPT partition type. go ahead, show your code, then we can talk about it. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Large (3TB) HDD support
On Sat, Jun 02, 2012 at 09:44:35AM +1000, David Diggles wrote: On Fri, Jun 01, 2012 at 04:32:19PM -0700, Chris Cappuccio wrote: Nick Holland [n...@holland-consulting.net] wrote: * you don't want to fsck a 3TB file system, 'specially if it is rebuilding the mirror at the same time, though with 12G RAM, you might be able to do it. Isn't this situation seriously improved with fsck in 5.1 ? I fsck'd two 3TB filesystems yesterday with 512MB ram, on 5.1... it took a while, but worked. What a bummer, the Dell Precision 690 I am currently trying does not support 2TB on its SAS or SATA controller. Oddly, the SATA controller presents it correctly as 2.8T, but it will not mount. The SAS controller on the other hand, presents it 2T. Latest BIOS firmwares for it are 2007, so figures. The 3TB disk is fine mounted over USB: OpenBSD 5.1 (GENERIC.MP) #207: Sun Feb 12 09:42:14 MST 2012 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4291862528 (4093MB) avail mem = 4163448832 (3970MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf0450 (122 entries) bios0: vendor Dell Inc. version A08 date 04/25/2008 bios0: Dell Inc. Precision WorkStation 690 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET SLIC acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI2(S5) PCI3(S5) PCIF(S5) PCIG(S5) PCI5(S5) PCI6(S5) PCI7(S5) PCI8(S5) PCI9(S5) MOU_(S3) USB0(S3) USB1(S3) USB2(S3) USB3(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz, 2327.80 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF cpu0: 4MB 64b/line 16-way L2 cache cpu0: apic clock running at 332MHz cpu1 at mainbus0: apid 6 (application processor) cpu1: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz, 2327.50 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF cpu1: 4MB 64b/line 16-way L2 cache cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz, 2327.50 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF cpu2: 4MB 64b/line 16-way L2 cache cpu3 at mainbus0: apid 7 (application processor) cpu3: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz, 2327.50 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF cpu3: 4MB 64b/line 16-way L2 cache ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 8 ioapic1 at mainbus0: apid 9 pa 0xfec8, version 20, 24 pins ioapic1: misconfigured as apic 0, remapped to apid 9 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 1 (PCI2) acpiprt1 at acpi0: bus 2 (PCI3) acpiprt2 at acpi0: bus 3 (PCIF) acpiprt3 at acpi0: bus 4 (PCIG) acpiprt4 at acpi0: bus 5 (PCI5) acpiprt5 at acpi0: bus 6 (PCI6) acpiprt6 at acpi0: bus 7 (PCI7) acpiprt7 at acpi0: bus 11 (PCI8) acpiprt8 at acpi0: bus 12 (PCI9) acpiprt9 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 acpibtn0 at acpi0: VBTN memory map conflict 0xcfe0ec00/0x1f1400 memory map conflict 0xfec9/0x17 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel 5000X Host rev 0x12 ppb0 at pci0 dev 2 function 0 Intel 5000 PCIE rev 0x12 pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci2 at ppb1 bus 2 ppb2 at pci2 dev 0 function 0 Intel 6321ESB PCIE rev 0x01: msi pci3 at ppb2 bus 3 ppb3 at pci2 dev 1 function 0 Intel 6321ESB PCIE rev 0x01: msi pci4 at ppb3 bus 4 ppb4 at pci1 dev 0 function 3 Intel 6321ESB PCIE-PCIX rev 0x01 pci5 at ppb4 bus 5 mpi0 at pci5 dev 11 function 0 Symbios Logic SAS1068 rev 0x01: msi scsibus0 at mpi0: 112 targets sd0 at scsibus0 targ 0 lun 0: ATA, WDC WD1500HLFS-0, 4V01 SCSI3 0/direct fixed naa.50014ee0562fc45b sd0: 143089MB, 512 bytes/sector, 293046768 sectors ppb5 at pci0 dev 3 function 0 Intel 5000 PCIE rev 0x12: msi pci6 at ppb5 bus 6 ppb6 at pci0 dev 4 function 0 Intel 5000 PCIE x16 rev 0x12: msi pci7 at ppb6 bus 7 vga1 at pci7 dev 0 function 0 NVIDIA Quadro FX 3500 rev 0xa1 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb7 at pci0 dev 5 function 0 Intel 5000 PCIE rev 0x12 pci8 at ppb7 bus 8 ppb8 at pci0 dev 6 function 0 Intel 5000 PCIE rev 0x12 pci9 at ppb8 bus 9 ppb9 at pci0 dev 7
Re: Large (3TB) HDD support
On 06/05/2012 07:40 AM, David Diggles wrote: ... What a bummer, the Dell Precision 690 I am currently trying does not support 2TB on its SAS or SATA controller. Oddly, the SATA controller presents it correctly as 2.8T, but it will not mount. The SAS controller on the other hand, presents it 2T. will not mount -- what does that mean? What did you do, what did you see happen? Nick.
Re: Large (3TB) HDD support
On Tue, Jun 05, 2012 at 09:40:15AM -0400, Nick Holland wrote: On 06/05/2012 07:40 AM, David Diggles wrote: ... What a bummer, the Dell Precision 690 I am currently trying does not support 2TB on its SAS or SATA controller. Oddly, the SATA controller presents it correctly as 2.8T, but it will not mount. The SAS controller on the other hand, presents it 2T. will not mount -- what does that mean? What did you do, what did you see happen? Nick. Sorry Nick, I lost the record I made, of what I tried and what happened. I will gather this information again and provide it tomorrow, including firmware versions, dmesg, fdisk and disklabel outputs, mount error and fsck error message. One thing is certain - fsck complained of bad magic number and couldn't find a superblock, with both the SAS and SATA controller.
Re: Large (3TB) HDD support
2012/6/1 Tyler Morgan tyl...@tradetech.net: http://www.openbsd.org/faq/faq14.html#LargeDrive That doesn't mention GPT, which is the problem with drives 2TB. https://en.wikipedia.org/wiki/GUID_Partition_Table Can OpenBSD already boot from a 4TB drive on an UEFI system? Try to buy systems that don't rely on UEFI. In the next few years, prepare to buy systems and find out they require UEFI, and then demand a refund. Prepare for it to get even worse than that. There are already a number of BIOSes out there capable of nasty (or really cool) stuff pre-OS boot. The BIOS setup page may look like a DOS relic but it doesn't mean it actually is. F.ex. prior to Vista's launch, MS demoed a fullscreen video before any boot code was actually run. UEFI has gotten more press, and given RH an opportunity to present itself as defender of freedom, but it's really an evolution of PCs running black-box code when and where it can do most harm. -- p
Re: Large (3TB) HDD support
Of course, it isn't /quite/ that simple. GPT is still fairly new, and whilst it's not too difficult to get a number of operating systems to boot from GPT, sharing a disk has a number of gotchas. Exposing dormant OpenBSD partitions to an untrusted OS is stupid unless you have no other choice like on a single-HDD laptop -- but it's unlikely to be a 3TB HDD. I think docs should actively discourage multibooting and present it as a potential risk rather than a feature so people stop bragging how many OSes they crammed on a single disk. Most live-CD firmware updates should also be done with the OpenBSD HDD unplugged. -- p
Re: Large (3TB) HDD support
On Mon Jun 4 2012 08:16, Peter Laufenberg wrote: UEFI has gotten more press, and given RH an opportunity to present itself as defender of freedom, but it's really an evolution of PCs running black-box code when and where it can do most harm. In fact, RH betrayed the OSS community by not trying to exert at least some pressure on the big players in the mainboard industry, willing to implement UEFI with Secure Boot adhering to MS's constraints. RH was probably the only big OSS vendor with powers to fight against that pervert situation in that every boot code out there needs to be signed by MS. They probably say, it's only 99 dollars, so what? It's isn't worth the hassle, let's take the most convenient option, which works for us. We don't care for you, outlandish operating system (OSS) vendors ... very sad. Norman.
Re: Large (3TB) HDD support
On Mon, Jun 04, 2012 at 12:16:26AM +0200, frantisek holop wrote: hmm, on Sun, Jun 03, 2012 at 01:39:18PM +0200, Tobias Ulmer said that these must be some really nice disks :] for example only a 200G slice (also 64k/8k) of music/film/picture collection (not even full yet) on a notebook disk (5400 RPM) takes ages: Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on /dev/sd0d 217G153G 63.5G71% 44815 7197423 1% /data $ time sudo fsck -f /dev/sd0d ** /dev/rsd0d ** File system is already clean ** Last Mounted on /data ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 44815 files, 20076091 used, 8329340 free (13748 frags, 1039449 blocks, 0.0% fragmentation) 4m58.26s real 0m22.50s user 0m7.28s system at 71% disk usage having 1% inode usage, would it be a logical idea to radically slash the number of inodes, perhaps by 50%, even more? if i had 50% of the current total inodes, would the fsck time be halved? for some reason it seemed logical that checking free inodes will be much faster then used ones... This comes down to the FFS1 vs FFS2 difference. Newfs will select FFS2 for bigger filesystems, reducing fsck times significantly at the expense of more efficient disk space allocation in FFS1. by efficient disk space allocation you mean fragmentation? are there any numbers comparing FFS1 to FFS2 in this regard? would there be a perceptible (negative) effect of using FFS2 on slices smaller than 1TB? -f -- experience is nothing but a lot of mistakes. There are two major differences between ffs1 en ffs2 1. ffs2 inodes are twice as big, since the block number sizes have doubled. This has the consequence that the meta data of a ffs2 filesystem take more space. 2. ffs2 initializes inode blocks on a 'as needed' approach. So on a typical filesystem, you have far less inode active blocks compared to the ffs1 situation. (that also explains the much quicker newfs on a ffs2 filesystem). Empty inodes do need to be check to see if they are really empty (do not refer blocks allocated elsewhere), while nonexistent inodes you do not have to/cannot check. That largely explains the speed difference. For smaller file systems, using ffs2 can speed fsck up, but you'll waste some more space on meta data. Note that inode blocks in the ffs2 case always are reserved, the unused inode blocks still take up space. -Otto
Re: Large (3TB) HDD support
On Mon Jun 4 2012 08:16, Peter Laufenberg wrote: UEFI has gotten more press, and given RH an opportunity to present itself as defender of freedom I meant that sarcastically -- p
Re: Large (3TB) HDD support
On Mon Jun 4 2012 11:46, Peter Laufenberg wrote: On Mon Jun 4 2012 08:16, Peter Laufenberg wrote: UEFI has gotten more press, and given RH an opportunity to present itself as defender of freedom I meant that sarcastically Sure you did. I just wanted to highlight this point even more.
Re: Large (3TB) HDD support
On Mon Jun 4 2012 08:16, Peter Laufenberg wrote: UEFI has gotten more press, and given RH an opportunity to present itself as defender of freedom, but it's really an evolution of PCs running black-box code when and where it can do most harm. In fact, RH betrayed the OSS community It's not exactly their 1st offence :) They probably say, it's only 99 dollars, so what? $99 is too little, hopefully they'll charge a lot more so they'll break economies of scale while users scramble to avoid Win8 and possibly we'll see mobos without a mind-boggling array of environmental sensors every web browser already wired to javascript. -- p
Re: Large (3TB) HDD support
Peter Kay syllops...@syllopsium.co.uk wrote: GPT is a foregone conclusion unless you are blind to the future. The only alternative is OS specific disk hackery, and that does no-one any favours. Well, OpenBSD/i386 (and now /amd64) has used such hackery since the very beginning and doesn't fare too badly with it. Back in the day, I used to run FreeBSD with dangerously dedicated disks that didn't have MBR partitioning at all, just a pure BSD disklabel. (FreeBSD eventually discouraged/abolished this due to some BIOSes refusing to boot disks without an MBR partition table.) GPT's main selling point is that it is superior to MBR if you use either as your native partitioning scheme. That doesn't apply to OpenBSD. GPT is also useful if you want different operating systems to coexist on the same disk. For OpenBSD, that's more of a grudgingly tolerated configuration and not recommended. -- Christian naddy Weisgerber na...@mips.inka.de
Re: Large (3TB) HDD support
On 4 June 2012 15:06, Christian Weisgerber na...@mips.inka.de wrote: Peter Kay syllops...@syllopsium.co.uk wrote: GPT is a foregone conclusion unless you are blind to the future. The only alternative is OS specific disk hackery, and that does no-one any favours. Well, OpenBSD/i386 (and now /amd64) has used such hackery since the very beginning and doesn't fare too badly with it. Back in the day, I used to run FreeBSD with dangerously dedicated disks that didn't have MBR partitioning at all, just a pure BSD disklabel. (FreeBSD eventually discouraged/abolished this due to some BIOSes refusing to boot disks without an MBR partition table.) Let's leave aside the boot techie stuff which I included mainly as a interesting (to me) related point. I don't have a particular issue with most of the disk hackery that OpenBSD currently performs, but the key detail is that at least under x86, powermac and sgi platforms [1] it seems to work within the boundaries of the native disk partitioning by using a custom disk format, performing custom partition labelling or using a native partition as a container for a custom format (disklabel inside MBR partition). That strategy tends to co-exist quite nicely with other tools/BIOSes/OSes that might inadvertently read the disk (with the exception of the pure BSD disklabel as you say). That's not the case with storing data outside the 2TB limit enforced by the MBR design. It seems to me it would be more sensible to stick a disklabel inside a new OpenBSD GPT partition type. All the data are successfully protected by a known standard and both the users and disk tools are happy. I'll grant that multiboot is a rare and usually inadvisable configuration (although I'd suggest it's useful on laptops sometimes), but protecting all the data on a uniboot system sounds advisable. GPT's main selling point is that it is superior to MBR if you use either as your native partitioning scheme. That doesn't apply to OpenBSD. GPT is also useful if you want different operating systems to coexist on the same disk. For OpenBSD, that's more of a grudgingly tolerated configuration and not recommended. [1] I don't have experience of the other platforms apart than sparc, and that was some time ago.
Re: Large (3TB) HDD support
I don't have a particular issue with most of the disk hackery that OpenBSD currently performs, but the key detail is that at least under x86, powermac and sgi platforms [1] it seems to work within the boundaries of the native disk partitioning by using a custom disk format, performing custom partition labelling or using a native partition as a container for a custom format (disklabel inside MBR partition). That strategy tends to co-exist quite nicely with other tools/BIOSes/OSes that might inadvertently read the disk (with the exception of the pure BSD disklabel as you say). That's not the case with storing data outside the 2TB limit enforced by the MBR design. It seems to me it would be more sensible to stick a disklabel inside a new OpenBSD GPT partition type. All the data are successfully protected by a known standard and both the users and disk tools are happy. The openbsd disklabel can reach up that high easily. The GPT changes nothing. That is just a stub pointing at where openbsd is. You are not talking about partitions we handle here, but about something the bootloader sets up and then we forget about it forever. I'll grant that multiboot is a rare and usually inadvisable configuration (although I'd suggest it's useful on laptops sometimes), but protecting all the data on a uniboot system sounds advisable. There is nothing preventing someone with a GPT + covering MBR from setting up the GPT (which in their case has been mangled by many operating systems) to cover all the OpenBSD space nicely. But the tools our install scripts use do not do that. And you are going to start work on a replacement for fdisk tomorrow, that can do all the MBR stuff still, but also handle GPT? The people who want multiboot to work in a GPT-only-world that they -- and only they -- see coming should really write the code themselves. At this moment, the GPT-only systems that exist come from a vendor that does not envision multiboot, either. Why hold people who you don't pay to a higher standard than the people who you do pay?
Re: Large (3TB) HDD support
hmm, on Sat, Jun 02, 2012 at 10:44:22AM +, Christian Weisgerber said that Otto Moerbeek o...@drijf.net wrote: I just fsck'ed a 2.7TB filesystem in 1 minute, 43 seconds. 61% full, 447166 files. What CPU and how much RAM? SATA2 or 3? Even more important: block size, fragment size, # of inodes? Default values all the way. 64k/8k. Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on /dev/sd1d 2.7T1.6T1.0T61% 447167 91273535 0% /export Watching this with top, I see fsck_ffs grow to a measly ~44 MB resident size. these must be some really nice disks :] for example only a 200G slice (also 64k/8k) of music/film/picture collection (not even full yet) on a notebook disk (5400 RPM) takes ages: Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on /dev/sd0d 217G153G 63.5G71% 44815 7197423 1% /data $ time sudo fsck -f /dev/sd0d ** /dev/rsd0d ** File system is already clean ** Last Mounted on /data ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 44815 files, 20076091 used, 8329340 free (13748 frags, 1039449 blocks, 0.0% fragmentation) 4m58.26s real 0m22.50s user 0m7.28s system i am more than curious about your amd thread, i am trying to get rid of fsck times by creative disklabeling and mounting read-only... -f -- there are 3 kinds of people: those who can count those who can't.
Re: Large (3TB) HDD support
hmm, on Fri, Jun 01, 2012 at 08:06:24PM +, Christian Weisgerber said that Scott McEachern sc...@blackstaff.ca wrote: I'm trying to add a pair of 3TB drives to my workstation, which I plan on turning into a ~3TB RAID 1 array, and seem to be having difficulty realizing the full size of the drives. The partition table in the MBR is limited to 32-bit numbers. 512 bytes/sector * 2^32 sectors = 2 TB In practice, fdisk -i will create an OpenBSD MBR partition of a size modulo 2 TB. If you don't share the disk with other operating systems, this doesn't matter. In disklabel, use the 'b' command to set the upper end of the OpenBSD disk boundary to the entire size of the disk. You can then make full use of the drive when creating partitions. looks like a perfect addition to the large disk FAQ. -f -- if you live long enough, it will kill you...
Re: Large (3TB) HDD support
On Sun, Jun 03, 2012 at 01:09:16PM +0200, frantisek holop wrote: hmm, on Sat, Jun 02, 2012 at 10:44:22AM +, Christian Weisgerber said that Otto Moerbeek o...@drijf.net wrote: I just fsck'ed a 2.7TB filesystem in 1 minute, 43 seconds. 61% full, 447166 files. What CPU and how much RAM? SATA2 or 3? Even more important: block size, fragment size, # of inodes? Default values all the way. 64k/8k. Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on /dev/sd1d 2.7T1.6T1.0T61% 447167 91273535 0% /export Watching this with top, I see fsck_ffs grow to a measly ~44 MB resident size. these must be some really nice disks :] for example only a 200G slice (also 64k/8k) of music/film/picture collection (not even full yet) on a notebook disk (5400 RPM) takes ages: Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on /dev/sd0d 217G153G 63.5G71% 44815 7197423 1% /data $ time sudo fsck -f /dev/sd0d ** /dev/rsd0d ** File system is already clean ** Last Mounted on /data ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 44815 files, 20076091 used, 8329340 free (13748 frags, 1039449 blocks, 0.0% fragmentation) 4m58.26s real 0m22.50s user 0m7.28s system This comes down to the FFS1 vs FFS2 difference. Newfs will select FFS2 for bigger filesystems, reducing fsck times significantly at the expense of more efficient disk space allocation in FFS1. i am more than curious about your amd thread, i am trying to get rid of fsck times by creative disklabeling and mounting read-only... -f -- there are 3 kinds of people: those who can count those who can't.
Re: Large (3TB) HDD support
hmm, on Sun, Jun 03, 2012 at 01:39:18PM +0200, Tobias Ulmer said that these must be some really nice disks :] for example only a 200G slice (also 64k/8k) of music/film/picture collection (not even full yet) on a notebook disk (5400 RPM) takes ages: Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on /dev/sd0d 217G153G 63.5G71% 44815 7197423 1% /data $ time sudo fsck -f /dev/sd0d ** /dev/rsd0d ** File system is already clean ** Last Mounted on /data ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 44815 files, 20076091 used, 8329340 free (13748 frags, 1039449 blocks, 0.0% fragmentation) 4m58.26s real 0m22.50s user 0m7.28s system at 71% disk usage having 1% inode usage, would it be a logical idea to radically slash the number of inodes, perhaps by 50%, even more? if i had 50% of the current total inodes, would the fsck time be halved? for some reason it seemed logical that checking free inodes will be much faster then used ones... This comes down to the FFS1 vs FFS2 difference. Newfs will select FFS2 for bigger filesystems, reducing fsck times significantly at the expense of more efficient disk space allocation in FFS1. by efficient disk space allocation you mean fragmentation? are there any numbers comparing FFS1 to FFS2 in this regard? would there be a perceptible (negative) effect of using FFS2 on slices smaller than 1TB? -f -- experience is nothing but a lot of mistakes.
Re: Large (3TB) HDD support
Can we please differentiate GPT from EFI. GPT may be part of the EFI specification, but it's a standalone piece - implementing GPT is not going to restrict anyone's freedom to do what they want with a machine. Some possibilities EFI offers are more contentious.. GPT is a foregone conclusion unless you are blind to the future. The only alternative is OS specific disk hackery, and that does no-one any favours. Single disk 2TB+ partitions will not even attract comment inside the next 5 years. Several operating systems out there can happily read GPT disks using a non EFI BIOS (provided it's not necessary to boot from it), and even in the case where it's a GPT disk with a GPT only OS (i.e OS X Intel) on a non EFI BIOS, there are workarounds to get it to boot. Of course, it isn't /quite/ that simple. GPT is still fairly new, and whilst it's not too difficult to get a number of operating systems to boot from GPT, sharing a disk has a number of gotchas. Google is your friend for details here. I can also say, having done it (and the fact it's not easily googleable) that although 'hybrid GPTs' (a GPT disk where the protective fake MBR is hacked to become a real MBR) are frowned upon (there is potential for breakage) it does work and it's even possible to hack in an extended partition (OpenBSD's Fdisk is much better than the alternatives for doing this piece of hackery). It's entirely possible to get a disk sharing OpenBSD, NetBSD, Linux, Vista Windows 7 and OS X without any of them overwriting data from the others. Just be careful. (for clarity, OS X was the only OS using a real GPT partition : everything else was on MBR, despite the fact that Windows 7/Vista SP2 x64 (not 32bit), Linux and NetBSD will boot from GPT partitions with appropriate hackery. Note that IIRC vanilla NetBSD 5.x will need a customised kernel to run from a hybrid MBR on GPT, otherwise it gets confused by the presence of a GPT header. The boot loader was the hackintosh chameleon with Windows 7's partition manager as a slave (very flexible once you get to know it. Use easyBCD))
Re: Large (3TB) HDD support
Can we please differentiate GPT from EFI. GPT may be part of the EFI specification, but it's a standalone piece - implementing GPT is not going to restrict anyone's freedom to do what they want with a machine. Some possibilities EFI offers are more contentious.. You are turning it upside down. Noone claimed that. GPT is a foregone conclusion unless you are blind to the future. The only alternative is OS specific disk hackery, and that does no-one any favours. Single disk 2TB+ partitions will not even attract comment inside the next 5 years. In OpenBSD on a non-GPT machine, I can have fifteen 2^48 block partitions per disk, now. GPT adds nothing that is neccesary. Several operating systems out there can happily read GPT disks using a non EFI BIOS (provided it's not necessary to boot from it), and even in the case where it's a GPT disk with a GPT only OS (i.e OS X Intel) on a non EFI BIOS, there are workarounds to get it to boot. You are the only person talking about GPT being neccessary, and now you are saying that is for other operating systems. Of course, it isn't /quite/ that simple. GPT is still fairly new, and whilst it's not too difficult to get a number of operating systems to boot from GPT, sharing a disk has a number of gotchas. Google is your friend for details here. Sharing? I specifically said that the normal user won't care. That's because the normal user does not install multiple operating systems on a single disk. I can also say, having done it (and the fact it's not easily googleable) that although 'hybrid GPTs' (a GPT disk where the protective fake MBR is hacked to become a real MBR) are frowned upon (there is potential for breakage) it does work and it's even possible to hack in an extended partition (OpenBSD's Fdisk is much better than the alternatives for doing this piece of hackery). It's entirely possible to get a disk sharing OpenBSD, NetBSD, Linux, Vista Windows 7 and OS X without any of them overwriting data from the others. Just be careful. GPT is required for large disk OS sharing? Perhaps. And, who cares? (for clarity, OS X was the only OS using a real GPT partition : everything else was on MBR, despite the fact that Windows 7/Vista SP2 x64 (not 32bit), Linux and NetBSD will boot from GPT partitions with appropriate hackery. Note that IIRC vanilla NetBSD 5.x will need a customised kernel to run from a hybrid MBR on GPT, otherwise it gets confused by the presence of a GPT header. The boot loader was the hackintosh chameleon with Windows 7's partition manager as a slave (very flexible once you get to know it. Use easyBCD)) Before you, this conversation was not about multi-booting machines. It specifically excluded that case.
Re: Large (3TB) HDD support
On Sun, Jun 3, 2012 at 9:18 PM, Peter Kay syllops...@syllopsium.co.uk wrote: Can we please differentiate GPT from EFI. GPT may be part of the EFI specification, but it's a standalone piece - implementing GPT is not going to restrict anyone's freedom to do what they want with a machine. Some possibilities EFI offers are more contentious.. GPT is a foregone conclusion unless you are blind to the future. The only alternative is OS specific disk hackery, and that does no-one any favours. Single disk 2TB+ partitions will not even attract comment inside the next 5 years. it doesn't make sense to put my boot files / os on a 2tb file system. whether or not this will eventually become a non-issue, i don't see any oses significantly moving in the opposite direction. not even windows 7 shys away from having a small boot partition. there's also no os out there that benefits from having 2tb to move about the boot partition, let alone to house system files. that could change but not any time soon, and most definitely not in the next 5 years
Re: Large (3TB) HDD support
Otto Moerbeek o...@drijf.net wrote: I just fsck'ed a 2.7TB filesystem in 1 minute, 43 seconds. 61% full, 447166 files. What CPU and how much RAM? SATA2 or 3? Even more important: block size, fragment size, # of inodes? Default values all the way. 64k/8k. Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on /dev/sd1d 2.7T1.6T1.0T61% 447167 91273535 0% /export Watching this with top, I see fsck_ffs grow to a measly ~44 MB resident size. -- Christian naddy Weisgerber na...@mips.inka.de
Re: Large (3TB) HDD support
On 6/1/2012 10:04 AM, Scott McEachern wrote: Hello everyone, I'm hoping that I'm missing something simple (like usual) and maybe someone could straighten me out. I'm trying to add a pair of 3TB drives to my workstation, which I plan on turning into a ~3TB RAID 1 array, and seem to be having difficulty realizing the full size of the drives. http://www.openbsd.org/faq/faq14.html#LargeDrive I don't have any experience using disks this large in OpenBSD, but ye olde fine print: Note that not all controllers and drivers support large disks. For example, ami(4) has a limit of 2TB per logical volume. Always be aware of what was available when a controler or interface was manufactured, and don't just rely on the connectors fit. However, it's far from hopeless, yet...
Re: Large (3TB) HDD support
On Fri, Jun 01, 2012 at 01:04:54PM -0400, Scott McEachern wrote: Hello everyone, I'm hoping that I'm missing something simple (like usual) and maybe someone could straighten me out. I'm trying to add a pair of 3TB drives to my workstation, which I plan on turning into a ~3TB RAID 1 array, and seem to be having difficulty realizing the full size of the drives. The hardware is about a year old, and less than two years old according to the BIOS date: bios0: vendor American Megatrends Inc. version 2103 date 06/18/2010 bios0: ASUSTeK Computer INC. M4A785TD-V EVO (Correction, I've since updated the BIOS to the latest version, just in case, and it reads like so: bios0: vendor American Megatrends Inc. version 2105 date 07/23/2010 and it makes no difference.) (The full dmesg is below, but for now I'll just post the relevant bits.) The BIOS happily reports the two drives as present and of 3.0TB capacity. OpenBSD seems to recognize this as well: sd0 at scsibus0 targ 0 lun 0: ATA, WDC WD5000AAKS-0, 05.0 SCSI3 0/direct fixed naa.50014ee001cbd923 sd0: 476940MB, 512 bytes/sector, 976773168 sectors sd1 at scsibus0 targ 1 lun 0: ATA, ST3000DM001-9YN1, CC4B SCSI3 0/direct fixed naa.5000c5004a6e56f1 sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors sd2 at scsibus0 targ 2 lun 0: ATA, ST3000DM001-9YN1, CC4B SCSI3 0/direct fixed naa.5000c5004a5baa2e sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors (Note that sd0 is my boot/OS drive, and works just fine. The two 3TB drives, sd1 and sd2, will eventually just be used for storage.) Those numbers look correct, like the OS is properly recognizing the capacity. I have a 1.5TB drive in another machine (a six year-old Pentium 4 no less!) that works fine and looks like this: wd0: 16-sector PIO, LBA48, 1430799MB, 2930277168 sectors (Although I should mention that that drive has a couple of 1TB partitions, so there are no FFS/FFS2 issues.) I just wanted to get on with my day and not have any fuss, so I issued an fdisk -iy sd1 command on the way to disklabel'ing things. I suspect that's my error, because fdisk says this: (I've added some commas to make for easier reading.) # fdisk sd1 Disk: sd1 geometry: 364801/255/63 [1,565,565,872 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 97451 165 59 [ 64: 1,565,560,705 ] OpenBSD Uhm, that doesn't seem right, considering the fdisk output for a 1.5TB drive looks like this: # fdisk wd0 Disk: wd0 geometry: 182401/255/63 [2,930,277,168 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 182400 254 63 [ 64: 2,930,272,001 ] OpenBSD A drive with half the capacity seems to have double the numbers, but not for geometry. I suspect that fdisk is lying to me, but I could be wrong. Let's see what disklabel(8) has to say. On the 1.5TB drive, it looks mostly like this (I've snipped some irrelevant partition data and added commas to make big numbers easier to read): # disklabel wd0 # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: ST31500341AS duid: dded65e423b05de7 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 182401 total sectors: 2,930,277,168 boundstart: 64 boundend: 2930272065 drivedata: 0 16 partitions: (snipped) #size offset fstype [fsize bsize cpg] c: 2,930,277,1680 unused On the new 3TB drive, it looks like this: # disklabel sd1 # /dev/rsd1c: type: SCSI disk: SCSI disk label: ST3000DM001-9YN1 duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 364801 total sectors: 5,860,533,168 boundstart: 64 boundend: 1565560769 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c: 5,860,533,1680 unused Wait a minute here... disklabel seems to have correct data (ignoring the duid). I'll bet I'm failing at grade four math, but that looks roughly
Re: Large (3TB) HDD support
2012/6/1 Tyler Morgan tyl...@tradetech.net: http://www.openbsd.org/faq/faq14.html#LargeDrive That doesn't mention GPT, which is the problem with drives 2TB. https://en.wikipedia.org/wiki/GUID_Partition_Table Can OpenBSD already boot from a 4TB drive on an UEFI system? Best Martin
Re: Large (3TB) HDD support
Otto gave you a good answer here, but I had already provided lots of detail, so I'm sending anyway. :) On 06/01/2012 01:04 PM, Scott McEachern wrote: Hello everyone, I'm hoping that I'm missing something simple (like usual) and maybe someone could straighten me out. I'm trying to add a pair of 3TB drives to my workstation, which I plan on turning into a ~3TB RAID 1 array, and seem to be having difficulty realizing the full size of the drives. The hardware is about a year old, and less than two years old according to the BIOS date: bios0: vendor American Megatrends Inc. version 2103 date 06/18/2010 bios0: ASUSTeK Computer INC. M4A785TD-V EVO (Correction, I've since updated the BIOS to the latest version, just in case, and it reads like so: bios0: vendor American Megatrends Inc. version 2105 date 07/23/2010 and it makes no difference.) (The full dmesg is below, but for now I'll just post the relevant bits.) The BIOS happily reports the two drives as present and of 3.0TB capacity. OpenBSD seems to recognize this as well: sd0 at scsibus0 targ 0 lun 0: ATA, WDC WD5000AAKS-0, 05.0 SCSI3 0/direct fixed naa.50014ee001cbd923 sd0: 476940MB, 512 bytes/sector, 976773168 sectors sd1 at scsibus0 targ 1 lun 0: ATA, ST3000DM001-9YN1, CC4B SCSI3 0/direct fixed naa.5000c5004a6e56f1 sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors sd2 at scsibus0 targ 2 lun 0: ATA, ST3000DM001-9YN1, CC4B SCSI3 0/direct fixed naa.5000c5004a5baa2e sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors Life is good. ... I just wanted to get on with my day and not have any fuss, so I issued an fdisk -iy sd1 command on the way to disklabel'ing things. I suspect that's my error, because fdisk says this: (I've added some commas to make for easier reading.) # fdisk sd1 Disk: sd1 geometry: 364801/255/63 [1,565,565,872 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 97451 165 59 [ 64: 1,565,560,705 ] OpenBSD Uhm, that doesn't seem right well. it's annoying, but rightish. :) fdisk edits MBRs, MBR has a limit of 2TB on its structures. So...it looks like fdisk basically did a 3TB modulo 2TB. I really should save myself looking like a fool and check my math, but if I'm wrong, it will teach you not to take what I say as gospel :) Some OSs want you to switch to a new way of handling big disks, but I do think OpenBSD will do what you want natively. .. A drive with half the capacity seems to have double the numbers, but not for geometry. I suspect that fdisk is lying to me, but I could be wrong. you are right. Let's see what disklabel(8) has to say. On the 1.5TB drive, it looks mostly like this (I've snipped some irrelevant partition data and added commas to make big numbers easier to read): .. total sectors: 2,930,277,168 boundstart: 64 boundend: 2930272065 drivedata: 0 16 partitions: (snipped) # size offset fstype [fsize bsize cpg] c: 2,930,277,168 0 unused On the new 3TB drive, it looks like this: # disklabel sd1 .. total sectors: 5,860,533,168 boundstart: 64 boundend: 1565560769 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] c: 5,860,533,168 0 unused Wait a minute here... disklabel seems to have correct data (ignoring the duid). I'll bet I'm failing at grade four math, but that looks roughly like a 3TB drive. yes, it's a 3TB disk, but at the moment, disklabel is restricting you to just the fdisk-marked part of the drive...which is as it should be. You generally don't want your OpenBSD partitions living outside the OpenBSD MBR (fdisk) partition. EXCEPT when the MBR isn't providing useful info. Like now. ... At this point I'm wondering WTF is going on. Is this an OpenBSD-specific problem? A BIOS issue? So I unplug all drives except one of the 3TB's, install FreeBSD and tell it to use the whole drive. I get the exact same results from their disklabel. Must be the hardware, right? What you want to do is use the 'b' option of disklabel to redefine the OpenBSD boundaries of the disk. I do believe it will let you specify the whole disk, and you can then do what you want. A few words of warning... * This really messes up your ability to multiboot, as non-OpenBSD OSs will think anything beyond the fdisk/MBR partition might be available. But then, most other OSs choke pretty badly at this point anyway. may not be that big a problem. * Lots of BIOSes that see 128G disks still won't let you boot from partitions higher than 128G. * I haven't actually TRIED this. I was planning on buying a 3TB disk to experiment on and update FAQ14...but just before I did, there was this little flood issue, and being a cheapskate, I didn't want to sink a lot of money into a drive I didn't really need quite yet (or more accurately, I need
Re: Large (3TB) HDD support
2012/6/1 Tyler Morgan tyl...@tradetech.net: http://www.openbsd.org/faq/faq14.html#LargeDrive That doesn't mention GPT, which is the problem with drives 2TB. https://en.wikipedia.org/wiki/GUID_Partition_Table Can OpenBSD already boot from a 4TB drive on an UEFI system? Try to buy systems that don't rely on UEFI. In the next few years, prepare to buy systems and find out they require UEFI, and then demand a refund. Prepare for it to get even worse than that. If you buy a UEFI-capable system today, you are giving power to the people who will (in the future) make UEFI-only systems which are incapable of running OpenBSD. UEFI arrived with all sorts of promises of making machines better, but is being turned into something completely nefarious.
Re: Large (3TB) HDD support
On Fri, Jun 01, 2012 at 09:26:41PM +0200, Martin Schr?der wrote: 2012/6/1 Tyler Morgan tyl...@tradetech.net: http://www.openbsd.org/faq/faq14.html#LargeDrive That doesn't mention GPT, which is the problem with drives 2TB. https://en.wikipedia.org/wiki/GUID_Partition_Table Can OpenBSD already boot from a 4TB drive on an UEFI system? Best Martin OpenBSD handles 2TB disks fine. A problem is that fdisk cannot correctly partiton such large disks, but disklabel is happy to ignore that fact using the b command. -Otto
Re: Large (3TB) HDD support
On 06/01/2012 03:26 PM, Martin Schrvder wrote: 2012/6/1 Tyler Morgantyl...@tradetech.net: http://www.openbsd.org/faq/faq14.html#LargeDrive That doesn't mention GPT, which is the problem with drives2TB. https://en.wikipedia.org/wiki/GUID_Partition_Table Can OpenBSD already boot from a 4TB drive on an UEFI system? Best Martin OpenBSD doesn't support booting from UEFI/GPT stuff at this point, but it is as needed as being able to boot from the tail of a 1TB disk when your bios only supports the first 32G. or 504M. or 128G. or whatever limit your BIOS has. It isn't needed. Hint: a lot of machines purchased today still have problems BOOTING beyond 128G, even though the BIOS reports the entire disk (and this is clearly a BIOS problem, I have several machines which DO boot fine beyond 128G), and you can use 2TB disks on those systems Just Fine. OpenBSD needs to load the boot loader from something the BIOS recognizes (an MBR/fdisk partition). From there, the OS has to be able to figure out where the rest of the disk is (disklabel). Look Ma, no UEFI! Now, if you want to multiboot four different OSs, and put OpenBSD as the last 500GB of a 3TB disk, not so pretty. Nick.
Re: Large (3TB) HDD support
Scott McEachern sc...@blackstaff.ca wrote: I'm trying to add a pair of 3TB drives to my workstation, which I plan on turning into a ~3TB RAID 1 array, and seem to be having difficulty realizing the full size of the drives. The partition table in the MBR is limited to 32-bit numbers. 512 bytes/sector * 2^32 sectors = 2 TB In practice, fdisk -i will create an OpenBSD MBR partition of a size modulo 2 TB. If you don't share the disk with other operating systems, this doesn't matter. In disklabel, use the 'b' command to set the upper end of the OpenBSD disk boundary to the entire size of the disk. You can then make full use of the drive when creating partitions. -- Christian naddy Weisgerber na...@mips.inka.de
Re: Large (3TB) HDD support
On 06/01/2012 03:41 PM, Theo de Raadt wrote: 2012/6/1 Tyler Morgantyl...@tradetech.net: http://www.openbsd.org/faq/faq14.html#LargeDrive That doesn't mention GPT, which is the problem with drives2TB. https://en.wikipedia.org/wiki/GUID_Partition_Table Can OpenBSD already boot from a 4TB drive on an UEFI system? Try to buy systems that don't rely on UEFI. In the next few years, prepare to buy systems and find out they require UEFI, and then demand a refund. Prepare for it to get even worse than that. If you buy a UEFI-capable system today, you are giving power to the people who will (in the future) make UEFI-only systems which are incapable of running OpenBSD. UEFI arrived with all sorts of promises of making machines better, but is being turned into something completely nefarious. On the surface, UEFI seems to allow the manufacturer and others to insert any amount of black-box malware during boot. That's enough to make me shudder. Obviously, opportunities abound for that code to prevent unauthorized O/Ses from running or subvert them once running. Are there other and larger issues? On the other hand, GPT by itself appears useful. Does it also contain boobytraps? Thanks! Geoff Steckel
Re: Large (3TB) HDD support
On the other hand, GPT by itself appears useful. What is useful about GPT? *EVERY USER* has the following simple requirements: 1. I have a machine. 2. I want to install an operating system on it (or, have an operating system installed from the factory) What am I missing -- what is useful about GPT? I guess I mean -- what is *MORE* useful about GPT, compared to the other options already available? I guess I should be even more clear: Does GPT provide any functionality that *EVERY USER* needs? No, it does not.
Re: Large (3TB) HDD support
On 06/01/2012 04:55 PM, Theo de Raadt wrote: On the other hand, GPT by itself appears useful. What is useful about GPT? *EVERY USER* has the following simple requirements: 1. I have a machine. 2. I want to install an operating system on it (or, have an operating system installed from the factory) What am I missing -- what is useful about GPT? I guess I mean -- what is *MORE* useful about GPT, compared to the other options already available? I guess I should be even more clear: Does GPT provide any functionality that *EVERY USER* needs? No, it does not. I agree completely that any OS can write any kind of disk label (or none) that it needs. As you say, in the very, very large majority of cases no FDISK or GPT or anything else external to the loaded OS is needed. The apparent advantage of GPT over FDISK partitions is that it can describe partitions 2TB for systems hosting multiple OSes. That's all I meant. Sorry that it wasn't clear. Geoff Steckel
Re: Large (3TB) HDD support
The apparent advantage of GPT over FDISK partitions is that it can describe partitions 2TB for systems hosting multiple OSes. That's all I meant. Sorry that it wasn't clear. US-based missile-armed predator drones by themselves appear useful.
Re: Large (3TB) HDD support
On Fri, Jun 1, 2012, at 03:27 PM, Nick Holland wrote: Otto gave you a good answer here, but I had already provided lots of detail, so I'm sending anyway. :) On 06/01/2012 01:04 PM, Scott McEachern wrote: Hello everyone, I'm hoping that I'm missing something simple (like usual) and maybe someone could straighten me out. I'm trying to add a pair of 3TB drives to my workstation, which I plan on turning into a ~3TB RAID 1 array, and seem to be having difficulty realizing the full size of the drives. The hardware is about a year old, and less than two years old according to the BIOS date: bios0: vendor American Megatrends Inc. version 2103 date 06/18/2010 bios0: ASUSTeK Computer INC. M4A785TD-V EVO (Correction, I've since updated the BIOS to the latest version, just in case, and it reads like so: bios0: vendor American Megatrends Inc. version 2105 date 07/23/2010 and it makes no difference.) (The full dmesg is below, but for now I'll just post the relevant bits.) The BIOS happily reports the two drives as present and of 3.0TB capacity. OpenBSD seems to recognize this as well: sd0 at scsibus0 targ 0 lun 0: ATA, WDC WD5000AAKS-0, 05.0 SCSI3 0/direct fixed naa.50014ee001cbd923 sd0: 476940MB, 512 bytes/sector, 976773168 sectors sd1 at scsibus0 targ 1 lun 0: ATA, ST3000DM001-9YN1, CC4B SCSI3 0/direct fixed naa.5000c5004a6e56f1 sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors sd2 at scsibus0 targ 2 lun 0: ATA, ST3000DM001-9YN1, CC4B SCSI3 0/direct fixed naa.5000c5004a5baa2e sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors Life is good. ... I just wanted to get on with my day and not have any fuss, so I issued an fdisk -iy sd1 command on the way to disklabel'ing things. I suspect that's my error, because fdisk says this: (I've added some commas to make for easier reading.) # fdisk sd1 Disk: sd1 geometry: 364801/255/63 [1,565,565,872 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 97451 165 59 [ 64: 1,565,560,705 ] OpenBSD Uhm, that doesn't seem right well. it's annoying, but rightish. :) fdisk edits MBRs, MBR has a limit of 2TB on its structures. So...it looks like fdisk basically did a 3TB modulo 2TB. I really should save myself looking like a fool and check my math, but if I'm wrong, it will teach you not to take what I say as gospel :) Some OSs want you to switch to a new way of handling big disks, but I do think OpenBSD will do what you want natively. .. A drive with half the capacity seems to have double the numbers, but not for geometry. I suspect that fdisk is lying to me, but I could be wrong. you are right. Let's see what disklabel(8) has to say. On the 1.5TB drive, it looks mostly like this (I've snipped some irrelevant partition data and added commas to make big numbers easier to read): .. total sectors: 2,930,277,168 boundstart: 64 boundend: 2930272065 drivedata: 0 16 partitions: (snipped) # size offset fstype [fsize bsize cpg] c: 2,930,277,168 0 unused On the new 3TB drive, it looks like this: # disklabel sd1 .. total sectors: 5,860,533,168 boundstart: 64 boundend: 1565560769 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] c: 5,860,533,168 0 unused Wait a minute here... disklabel seems to have correct data (ignoring the duid). I'll bet I'm failing at grade four math, but that looks roughly like a 3TB drive. yes, it's a 3TB disk, but at the moment, disklabel is restricting you to just the fdisk-marked part of the drive...which is as it should be. You generally don't want your OpenBSD partitions living outside the OpenBSD MBR (fdisk) partition. EXCEPT when the MBR isn't providing useful info. Like now. ... At this point I'm wondering WTF is going on. Is this an OpenBSD-specific problem? A BIOS issue? So I unplug all drives except one of the 3TB's, install FreeBSD and tell it to use the whole drive. I get the exact same results from their disklabel. Must be the hardware, right? What you want to do is use the 'b' option of disklabel to redefine the OpenBSD boundaries of the disk. I do believe it will let you specify the whole disk, and you can then do what you want. A few words of warning... * This really messes up your ability to multiboot, as non-OpenBSD OSs will think anything beyond the fdisk/MBR partition might be available. But then, most other OSs choke pretty badly at this point anyway. may not be that big a problem. * Lots of BIOSes that see 128G disks still won't let you boot from partitions higher than 128G. * I haven't actually TRIED this. I was planning on buying a
Re: Large (3TB) HDD support
Nick Holland [n...@holland-consulting.net] wrote: * you don't want to fsck a 3TB file system, 'specially if it is rebuilding the mirror at the same time, though with 12G RAM, you might be able to do it. Isn't this situation seriously improved with fsck in 5.1 ?
Re: [OBSD Misc] Re: Large (3TB) HDD support
On Fri, Jun 1, 2012, at 03:27 PM, Nick Holland wrote: Otto gave you a good answer here, but I had already provided lots of detail, so I'm sending anyway. :) On 06/01/2012 01:04 PM, Scott McEachern wrote: Hello everyone, I'm hoping that I'm missing something simple (like usual) and maybe someone could straighten me out. I'm trying to add a pair of 3TB drives to my workstation, which I plan on turning into a ~3TB RAID 1 array, and seem to be having difficulty realizing the full size of the drives. The hardware is about a year old, and less than two years old according to the BIOS date: bios0: vendor American Megatrends Inc. version 2103 date 06/18/2010 bios0: ASUSTeK Computer INC. M4A785TD-V EVO (Correction, I've since updated the BIOS to the latest version, just in case, and it reads like so: bios0: vendor American Megatrends Inc. version 2105 date 07/23/2010 and it makes no difference.) (The full dmesg is below, but for now I'll just post the relevant bits.) The BIOS happily reports the two drives as present and of 3.0TB capacity. OpenBSD seems to recognize this as well: sd0 at scsibus0 targ 0 lun 0: ATA, WDC WD5000AAKS-0, 05.0 SCSI3 0/direct fixed naa.50014ee001cbd923 sd0: 476940MB, 512 bytes/sector, 976773168 sectors sd1 at scsibus0 targ 1 lun 0: ATA, ST3000DM001-9YN1, CC4B SCSI3 0/direct fixed naa.5000c5004a6e56f1 sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors sd2 at scsibus0 targ 2 lun 0: ATA, ST3000DM001-9YN1, CC4B SCSI3 0/direct fixed naa.5000c5004a5baa2e sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors Life is good. ... I just wanted to get on with my day and not have any fuss, so I issued an fdisk -iy sd1 command on the way to disklabel'ing things. I suspect that's my error, because fdisk says this: (I've added some commas to make for easier reading.) # fdisk sd1 Disk: sd1 geometry: 364801/255/63 [1,565,565,872 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 97451 165 59 [ 64: 1,565,560,705 ] OpenBSD Uhm, that doesn't seem right well. it's annoying, but rightish. :) fdisk edits MBRs, MBR has a limit of 2TB on its structures. So...it looks like fdisk basically did a 3TB modulo 2TB. I really should save myself looking like a fool and check my math, but if I'm wrong, it will teach you not to take what I say as gospel :) Some OSs want you to switch to a new way of handling big disks, but I do think OpenBSD will do what you want natively. .. A drive with half the capacity seems to have double the numbers, but not for geometry. I suspect that fdisk is lying to me, but I could be wrong. you are right. Let's see what disklabel(8) has to say. On the 1.5TB drive, it looks mostly like this (I've snipped some irrelevant partition data and added commas to make big numbers easier to read): .. total sectors: 2,930,277,168 boundstart: 64 boundend: 2930272065 drivedata: 0 16 partitions: (snipped) # size offset fstype [fsize bsize cpg] c: 2,930,277,168 0 unused On the new 3TB drive, it looks like this: # disklabel sd1 .. total sectors: 5,860,533,168 boundstart: 64 boundend: 1565560769 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] c: 5,860,533,168 0 unused Wait a minute here... disklabel seems to have correct data (ignoring the duid). I'll bet I'm failing at grade four math, but that looks roughly like a 3TB drive. yes, it's a 3TB disk, but at the moment, disklabel is restricting you to just the fdisk-marked part of the drive...which is as it should be. You generally don't want your OpenBSD partitions living outside the OpenBSD MBR (fdisk) partition. EXCEPT when the MBR isn't providing useful info. Like now. ... At this point I'm wondering WTF is going on. Is this an OpenBSD-specific problem? A BIOS issue? So I unplug all drives except one of the 3TB's, install FreeBSD and tell it to use the whole drive. I get the exact same results from their disklabel. Must be the hardware, right? What you want to do is use the 'b' option of disklabel to redefine the OpenBSD boundaries of the disk. I do believe it will let you specify the whole disk, and you can then do what you want. A few words of warning... * This really messes up your ability to multiboot, as non-OpenBSD OSs will think anything beyond the fdisk/MBR partition might be available. But then, most other OSs choke pretty badly at this point anyway. may not be that big a problem. * Lots of BIOSes that see
Re: Large (3TB) HDD support
On Fri, Jun 01, 2012 at 04:32:19PM -0700, Chris Cappuccio wrote: Nick Holland [n...@holland-consulting.net] wrote: * you don't want to fsck a 3TB file system, 'specially if it is rebuilding the mirror at the same time, though with 12G RAM, you might be able to do it. Isn't this situation seriously improved with fsck in 5.1 ? I fsck'd two 3TB filesystems yesterday with 512MB ram, on 5.1... it took a while, but worked.
Re: Large (3TB) HDD support
On Fri, 01 Jun 2012 13:41:21 -0600 Theo de Raadt wrote: UEFI arrived with all sorts of promises of making machines better, but is being turned into something completely nefarious. http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement Imagine if it came out before Vista and stopped everyone going back to the shops for XP ;-)
Re: Large (3TB) HDD support
On 2012-06-01, Chris Cappuccio ch...@nmedia.net wrote: Nick Holland [n...@holland-consulting.net] wrote: * you don't want to fsck a 3TB file system, 'specially if it is rebuilding the mirror at the same time, though with 12G RAM, you might be able to do it. Isn't this situation seriously improved with fsck in 5.1 ? Quite a lot. But you might still want to bump -i when you newfs (unless you actually need all those inodes). Default is based on the frag size, but there's a limit to frag size, so it stops scaling back the inode count after a point, and lots of inodes can really slow down fsck. If the majority of your files are media you might want to increase it a bit, if you're keeping large backups you might want to increase it a lot. From a bacula box... $ df -hi /bak Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on /dev/sd2m 2.7T1.4T1.2T56% 146 175212 0% /bak
Re: Large (3TB) HDD support
David Diggles da...@elven.com.au wrote: I fsck'd two 3TB filesystems yesterday with 512MB ram, on 5.1... it took a while, but worked. I just fsck'ed a 2.7TB filesystem in 1 minute, 43 seconds. 61% full, 447166 files. -- Christian naddy Weisgerber na...@mips.inka.de
Re: Large (3TB) HDD support
On 06/01/12 15:13, Otto Moerbeek wrote: Do a 'b *' command here, see the man page. That will make the whole disk available and the a command will do what you expect. -Otto Thank-you Otto and others for your assistance, that did the trick! I got both drives online, and set them up as a RAID 1 volume. A little geek porn if I may (I've never seen anything quite like that before. Ha! Until sthen@ posted his message): # df -h /st4 Filesystem SizeUsed Avail Capacity Mounted on /dev/sd3a 2.7T8.0K 2.6T 0%/st4 Some snipped dmesg: sd3 at scsibus3 targ 1 lun 0: OPENBSD, SR RAID 1, 005 SCSI2 0/direct fixed sd3: 2861588MB, 512 bytes/sector, 5860532640 sectors Now I can lighten the load on some of my other drives. :) On 06/01/12 15:27, Nick Holland wrote: 0/direct fixed naa.50014ee001cbd923 sd0: 476940MB, 512 bytes/sector, 976773168 sectors sd1 at scsibus0 targ 1 lun 0: ATA, ST3000DM001-9YN1, CC4B SCSI3 0/direct fixed naa.5000c5004a6e56f1 sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors sd2 at scsibus0 targ 2 lun 0: ATA, ST3000DM001-9YN1, CC4B SCSI3 0/direct fixed naa.5000c5004a5baa2e sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors Life is good. Oh, indeed! However, it'll take me at least a week to xfer my DVD stuff onto it... A few words of warning... * This really messes up your ability to multiboot, as non-OpenBSD OSs will think anything beyond the fdisk/MBR partition might be available. But then, most other OSs choke pretty badly at this point anyway. may not be that big a problem. I won't be multibooting this box any more. (It was once a triple boot WinXP/Win7/OpenBSD machine.) These days, I just buy really cheap used PCs for my occasional Windows needs. Life is easier with cheap hardware than bothering with multiple OSes on one box. * Lots of BIOSes that see 128G disks still won't let you boot from partitions higher than 128G. * I haven't actually TRIED this. I was planning on buying a 3TB disk to experiment on and update FAQ14...but just before I did, there was this little flood issue, and being a cheapskate, I didn't want to sink a lot of money into a drive I didn't really need quite yet (or more accurately, I need TWO of...) I was in the exact same boat; I'm a cheapskate too. I watched the same model drive double in price (about $180 CDN to about $400) overnight, and eventually they went down to $170. I kept scratching my chin on the idea, and the last straw was when (yet again) if I wanted a file (typically a movie), I'd have to dig up the DVD. I literally have hundreds of DVDs. It's seriously inconvenient to buy blanks, burn the data, hope it hasn't degraded when you need it, load it back... I figured Screw it, take the plunge. I think you know what I'd recommend... :) * Rebuilding the mirror will be a beast. * you don't want to fsck a 3TB file system, 'specially if it is rebuilding the mirror at the same time, though with 12G RAM, you might be able to do it. Nick. I'm hoping luck will stay on my side and I don't have to rebuild any time soon. And if things go sideways, which I always assume, I have other workstations I can use (that one just happens to be the 'best'). Good eye on noticing the 12GB of RAM; I'm sure that will come in handy when things go wrong. I'll be ordering a third 3TB drive as a spare, but in a while. I don't want them all to be from the same batch. I have a web server (Pentium 4) with two 40GB drives in RAID 1 as well, plus a spare in storage. (Not a typo, 40GB.) As you've written before, don't trust it, test it, so I pulled a drive, threw in my spare and let it rebuild. I believe that took half a day. I'm sure 3TB will be very, very ugly even on a machine considerably faster than a P4. BTW, I'm nicely UPSed and have pretty reliable hydro where I live, but stuff happens. That Pentium 4 with the 1.5TB drive only has 1GB of RAM, but I've been pleasantly surprised on the couple of times it's had to fsck the drive. I believe it only took about 10 minutes for it to sort things out the last time, but it's pretty much read-only. So thanks again folks for the advice! -- Scott McEachern https://www.blackstaff.ca
Re: Large (3TB) HDD support
On 06/01/12 20:54, Christian Weisgerber wrote: David Digglesda...@elven.com.au wrote: I fsck'd two 3TB filesystems yesterday with 512MB ram, on 5.1... it took a while, but worked. I just fsck'ed a 2.7TB filesystem in 1 minute, 43 seconds. 61% full, 447166 files. What CPU and how much RAM? SATA2 or 3? -- Scott McEachern https://www.blackstaff.ca
Re: Large (3TB) HDD support
On 06/01/12 19:18, Eric Furman wrote: Looks like Nick and OBSD could use a Donation. Anyone here in the community willing to step up and donate a couple 3TB drives? I would if I could so I understand if some people can't, but I'm sure there are a few people out there. I'm willing to step up. Hopefully, between your post and mine, we can get people to look under their cushions for spare change. :) I buy the CD sets and accessories like the rest of you, but honestly, it's been too long since I donated. Time to fix that situation. I could swing another 3TB drive, which is about $200 CDN, but not a pair. It was going to be my spare for the RAID array, but hey, it's time to give something back. My only question is whether the $200 for a 3TB drive is the best use of my donation. Is a big HDD actually useful to anyone? Would the money be better applied to something else that OpenBSD can use? It strikes me as rather pointless to order another drive, pay for shipping (even though it's only about $8), have it arrive and then ship it to someone else. (I'm sure my credit card company would be curious about why I'm buying something and having the goods shipped to a different address, possibly half-way around the world.) Enough of my yapping. I'm not interested in debating what's the best idea. I'm sure Theo can figure that out. Time to put up, and shut up, so I'm outta here. Order number 2012/6/1-19:42:43-30258: Your order currently is: - CDN $200.00 [DON] DONATION to the OpenBSD Project - Total: CDN $200.00 + Shipping. Danke, -- Scott McEachern https://www.blackstaff.ca
Re: Large (3TB) HDD support
On Fri, Jun 01, 2012 at 09:06:28PM -0400, Scott McEachern wrote: On 06/01/12 20:54, Christian Weisgerber wrote: David Digglesda...@elven.com.au wrote: I fsck'd two 3TB filesystems yesterday with 512MB ram, on 5.1... it took a while, but worked. I just fsck'ed a 2.7TB filesystem in 1 minute, 43 seconds. 61% full, 447166 files. What CPU and how much RAM? SATA2 or 3? Even more important: block size, fragment size, # of inodes? -Otto -- Scott McEachern https://www.blackstaff.ca
