I have two new 3TB disks. I'm adding them to an existing Debian (stable/ squeeze AMD64) system.
I plan to partition them, and make one large partition on each one to serve as a carrier for a RAID-1. I plan to subdivide that RAID using LVM. There will also be a few small partitions outside the RAID. If nothing wlse, they will enable me to distinguish the two physical drives in case I ever have to. In the longer future, I am considering moving to the btrfs when it is ready. I believe it subsumes some of the behaviour of RAID and LVM, as well as providing a number of other advantages. But since it is now under instense development, it's probably not a good bet aty the moment for storing critical data. (Yes, I also keep backups, just in case). I'm currently in the process of full-surface testing two new 3T disks, so I'll have a week or so before I'm ready to start using them. Just in case, to make sure I was testing the right drive (and not wiping out the smaller disks I'm already using) I first uses fdisk on all of my drives, so I'd know for sure which of /dev/sd* was a new one. It was quite clear. fdisk gave me a ton of warnings about the new drive, telling me I could not use a DOS-style parition table, and that fdisk was unable to serve me well, instead recomending paarted and GPT patition table format. It also warned me not to use a logical sector size that was smaller then the physical sector size, for severe performance reasone. Now currently my machine has two small (750G) disks that it stores the bulk of its files on, and one tiny (250G) IDE disk that it boots from. The new drives are intended to replace the existing 750G drives (which now contain RAID1-bearing partitions), but it wouldn't be terrible if instead I replaced the 250G boot disk and I set up to boot from one ogf the bigger SATA drives. (there's enough drive bays for four hard drives). Now when I look to Debian documentation for stable (which is the Debian I'm using on this server), I find http://www.debian.org/releases/stable/ i386/apcs05.html.en where I'm told there are three partitinoing programs: partman, fdisk, and cfdisk. There's no indicatino that any of these have problems with disks bigger than 2TiB. Documentatino for testing (at http://www.debian.org/releases/testing/i386/apcs05.html.en) is no better. I have several questions: (1) Is there up-to-date documentation on these matters. I'd love to RTFM if only I could find the FM. I gather I need to know about: (1a) sector size and how to choose it, (1b) disk block numbers more than 32 bits, (1c) file and partition size limits among ext2, 3, and 4. (my6 ext3's were migrated from ext2, so they may share the limits of the original ext2fs) (1d) EFI (1e) How this all affects booting (presumably with GRUB-2) in case I have a non-EFI BIOS (it is a somewhat old machine, having been build when SATA was just appearing on the market) (1f) Which of the utilities I'm used to will handle this large a disk with a new partitioning scheme and larger files -- things like fsck, badblocks, lvm, software RAID, rdiff-backup, grub, lilo, sqlite, etc. Id badblocks can't hacl it. for example. the full-service disk test I'm now doing may be useless. (1f) Whether all this would go better with wheezy instead of squeeze, and so whether I should upgrade squeeze to wheezy first. (1g) Would an up-to-date Debian installer take care of most of this stuff? It's not the way I [refer to go, because this machine is normally kept running 24 hours a day, and is actually used for much of this time. Reconfiguring a newly-installed system, instead of an upgrade, would be a pain. I probably need more than this, but I don't know enough to figure out what yet, so any good advice and especially warnings are welcome. Of course the most important stuff is related to how to get the system up and running, not things like whether Adobe Flash will fail. -- hendrik -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/k2vhvq$nuv$1...@ger.gmane.org
