On Wed, 18 Jun 2014 18:01:44 George Mitchell wrote: > A lot of good comments on this topic already. I would just add that on > large (TB) drives, not partitioning can result in some pretty slow mount > and umount times (even applies to mounting subvolumes).
If you mount a subvol then the kernel goes through the process of mounting the filesystem and makes just the subvol visible. Mounting a second subvol from that filesystem while the first is mounted should be instant. Mounting multiple filesystems on separate partitions should take longer than mounting a single large filesystem. If mounting a 4TB filesystem takes longer than 4*1TB filesystems then that would probably be a bug. > That is one of > the frustrating side effects I have noticed with a non-partitioned 4TB > drive on 32bit dual core pentium system. BTRFS can take a lot of CPU time (some of that is probably bugs in BTRFS). I wouldn't do anything serious with it on a 32bit system. That said there might be some performance bugs you are hitting so giving details about that on this list might be useful. > Additionally, with one big > partitionless drive, any serious defect on any part of the drive can > cost you the whole shebang, while, if partitioned, your loss is limited > to the affected partition. Backups are the first step to solving that problem. The next step is RAID, BTRFS allows you to convert to RAID-1 on the fly which is convenient for that situation. If you want to have data survive after getting errors in one part of a disk then you can run RAID-1 across 2 partitions on the same disk. Performance will be poor but it works well. I have a BTRFS RAID-1 on 2*1.5TB partitions on a 3TB disk that has ~100 bad sectors. It's working well for me. > I would also re-emphasize something that has > been mentioned by someone else already, which is that most partitioning > tools see a non-partitioned drive as being EMPTY, which can pose dangers > and risk costly mistakes with the push of a button. So there are > definitely some trade-offs. file(1) is one way of finding out what the disk is used for. Admittedly a Linux installation disk might have some problems, but it could mess up a partitioned disk just as easily. # file -s /dev/sd? /dev/sda: sticky x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 997376 sectors; partition 2: ID=0x82, starthead 53, startsector 999424, 1953792 sectors; partition 3: ID=0x83, starthead 211, startsector 2953216, 231487488 sectors, code offset 0x63 /dev/sdb: sticky BTRFS Filesystem sectorsize 4096, nodesize 4096, leafsize 4096) /dev/sdc: sticky BTRFS Filesystem sectorsize 4096, nodesize 4096, leafsize 4096) -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
