Hello If I want to manage a complete disk with btrfs, what''s the "Best Practice"? Would it be best to create the btrfs filesystem on "/dev/sdb", or would it be better to create just one partition from start to end and then do "mkfs.btrfs /dev/sdb1"? Would the same recomendation hold true, if we''re talking about huge disks, like 4TB or so? Cross platform compatibility (OS X, Windows, FreeBSD, …) is of no matter to me. Thanks, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/01/2013 04:51 PM, Alexander Skwar wrote:> Hello > > If I want to manage a complete disk with btrfs, what''s the "Best Practice"? > Would it be best to create the btrfs filesystem on "/dev/sdb", or would it be > better to create just one partition from start to end and then do "mkfs.btrfs > /dev/sdb1"? > > Would the same recomendation hold true, if we''re talking about huge disks, > like 4TB or so? > > Cross platform compatibility (OS X, Windows, FreeBSD, …) is of no matter to > me. > > Thanks, > Alexander(NB: grub will not boot from "/dev/sdb", selinux will) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 01, 2013 at 07:51:12AM +0000, Alexander Skwar wrote:> Hello > > If I want to manage a complete disk with btrfs, what''s the "Best Practice"? > Would it be best to create the btrfs filesystem on "/dev/sdb", or would it be > better to create just one partition from start to end and then do "mkfs.btrfs > /dev/sdb1"?I use full unpartitioned disks for my big array (8 devices, 9TB).> Would the same recomendation hold true, if we''re talking about huge disks, > like 4TB or so?Probably more so. DOS/MBR partitions have a size limit (although I must confess I don''t know what it is these days). You could partition with GPT in that instance, but probably better to just use the full device. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- emacs: Eats Memory and Crashes. ---
Hello dima dima <dolenin <at> parallels.com> writes:> (NB: grub will not boot from "/dev/sdb", selinux will)Fair point :) I don''t plan to boot from the disk, though. It''s a data disk, if you will. But, yeah, for a "best practice", that''s certainly something to keep in mind. BR, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 1 May 2013, dima <dolenin@parallels.com> wrote:> > If I want to manage a complete disk with btrfs, what''s the "Best > > Practice"? Would it be best to create the btrfs filesystem on > > "/dev/sdb", or would it be better to create just one partition from > > start to end and then do "mkfs.btrfs /dev/sdb1"? > > > > Would the same recomendation hold true, if we''re talking about huge > > disks, like 4TB or so?My biggest BTRFS array is a RAID-1 of 2*3TB disks. The system in question boots from an Intel SSD so I have no need of boot support on the hard disks.> (NB: grub will not boot from "/dev/sdb", selinux will)Not sure what you mean here, but SE Linux isn''t a boot loader. Did you mean syslinux? That''s a boot loader but I don''t know if it works in such a configuration. -- 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hallo, Alexander, Du meintest am 01.05.13:> If I want to manage a complete disk with btrfs, what''s the "Best > Practice"? Would it be best to create the btrfs filesystem on > "/dev/sdb", or would it be better to create just one partition from > start to end and then do "mkfs.btrfs /dev/sdb1"?> Would the same recomendation hold true, if we''re talking about huge > disks, like 4TB or so?I''ve tested both versions on a 3 disk bundle of 3 TByte disks (data raid0, meta raid1). mkfs.btrfs ... /dev/sdb /dev/sdc /dev/sdd made some more problems, especially when recognizing or deleting the disk(s). Maybe that''s a problem more related to "util-linux" (especially "wipefs" and "blkid"). Partitioning first with gdisk and then mkfs.btrfs ... /dev/sdb1 /dev/sdc1 /dev/sdd1 runs better (perhaps without problems). Viele Gruesse! Helmut -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/01/2013 05:44 PM, Russell Coker wrote:> On Wed, 1 May 2013, dima <dolenin@parallels.com> wrote: >>> If I want to manage a complete disk with btrfs, what''s the "Best >>> Practice"? Would it be best to create the btrfs filesystem on >>> "/dev/sdb", or would it be better to create just one partition from >>> start to end and then do "mkfs.btrfs /dev/sdb1"? >>> >>> Would the same recomendation hold true, if we''re talking about huge >>> disks, like 4TB or so? > > My biggest BTRFS array is a RAID-1 of 2*3TB disks. The system in question > boots from an Intel SSD so I have no need of boot support on the hard disks. > >> (NB: grub will not boot from "/dev/sdb", selinux will) > > Not sure what you mean here, but SE Linux isn''t a boot loader. Did you mean > syslinux? That''s a boot loader but I don''t know if it works in such a > configuration. >gosh! of course, SYSLINUX. Sorry guys. (i am working with selinux just now that is why....) Yes, syslinux will work, I had an install with root btrfs with syslinux as a bootloader (at the time when grub2 did not support booting from btrfs) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Hello > > If I want to manage a complete disk with btrfs, what''s the "Best > Practice"? Would it be best to create the btrfs filesystem on > "/dev/sdb", or would it be better to create just one partition from > start to end and then do "mkfs.btrfs /dev/sdb1"?Partitions (GPT) are always more flexible and future-proof. If you ever need to shrink the btrfs filesystem and give the space to another partition, or do a conversion to lvm/bcache/luks (shameless plug: https://github.com/g2p/blocks ), it''d be stupid to be locked into your current setup for want of a few megabytes of space before your filesystem.> Would the same recomendation hold true, if we''re talking about huge > disks, like 4TB or so?More so, since it can be infeasible to move this much data. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Helmut Hullen <Hullen@t-online.de> schrieb:>> If I want to manage a complete disk with btrfs, what''s the "Best >> Practice"? Would it be best to create the btrfs filesystem on >> "/dev/sdb", or would it be better to create just one partition from >> start to end and then do "mkfs.btrfs /dev/sdb1"? > >> Would the same recomendation hold true, if we''re talking about huge >> disks, like 4TB or so? > > I''ve tested both versions on a 3 disk bundle of 3 TByte disks (data > raid0, meta raid1). > > mkfs.btrfs ... /dev/sdb /dev/sdc /dev/sdd > > made some more problems, especially when recognizing or deleting the > disk(s). Maybe that''s a problem more related to "util-linux" (especially > "wipefs" and "blkid"). > > Partitioning first with gdisk and then > > mkfs.btrfs ... /dev/sdb1 /dev/sdc1 /dev/sdd1 > > runs better (perhaps without problems).I can only second that experience. Most apps and utilities do not expect filesystems on raw partitions, most expect partitions first. Some may even just destroy your filesystem because they only find what appears junk to them on the disk. OP is not going to dual-boot (which would raise such problems with the highest chance) but if you want to evade unexpected behavior use GPT partitioning - it supports huge disks and takes care on the block alignment. I used formatting raw disks in a VM because adding new disks was a matter of adding a new VD image to the machine and I didn''t need more than one partition on a disk. But that created more headache than I expected and I didn''t want to persuade tools and scripts any longer to accept raw disks as filesystems and work around ugly quirks (like scripts expecting /dev/sd[a-z] to never be a filesystem but always raw device, and requiring /dev/sd[a-z] [0-9]+ for partitions, and more such fun). So I suggest: Go with partitions. Regards, Kai -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/08/2013 12:31 AM, Kai Krakow wrote:> Helmut Hullen <Hullen@t-online.de> schrieb: > >>> If I want to manage a complete disk with btrfs, what''s the "Best >>> Practice"? Would it be best to create the btrfs filesystem on >>> "/dev/sdb", or would it be better to create just one partition from >>> start to end and then do "mkfs.btrfs /dev/sdb1"? >>> Would the same recomendation hold true, if we''re talking about huge >>> disks, like 4TB or so? >> I''ve tested both versions on a 3 disk bundle of 3 TByte disks (data >> raid0, meta raid1). >> >> mkfs.btrfs ... /dev/sdb /dev/sdc /dev/sdd >> >> made some more problems, especially when recognizing or deleting the >> disk(s). Maybe that''s a problem more related to "util-linux" (especially >> "wipefs" and "blkid"). >> >> Partitioning first with gdisk and then >> >> mkfs.btrfs ... /dev/sdb1 /dev/sdc1 /dev/sdd1 >> >> runs better (perhaps without problems). > I can only second that experience. Most apps and utilities do not expect > filesystems on raw partitions, most expect partitions first. Some may even > just destroy your filesystem because they only find what appears junk to > them on the disk. OP is not going to dual-boot (which would raise such > problems with the highest chance) but if you want to evade unexpected > behavior use GPT partitioning - it supports huge disks and takes care on the > block alignment. > > I used formatting raw disks in a VM because adding new disks was a matter of > adding a new VD image to the machine and I didn''t need more than one > partition on a disk. But that created more headache than I expected and I > didn''t want to persuade tools and scripts any longer to accept raw disks as > filesystems and work around ugly quirks (like scripts expecting /dev/sd[a-z] > to never be a filesystem but always raw device, and requiring /dev/sd[a-z] > [0-9]+ for partitions, and more such fun). > > So I suggest: Go with partitions. > > Regards, > Kai > > >I very much agree with that advice in the short term, however, in the longer term I am convinced that the larger ecosystem is going to have to catch up. Next gen filesystems like btrfs and zfs have made old standbys like block raid and lvm anachronisms an I really think that partitioning is not going to escape the same fate. Partitioning adds management overhead, wastes drive space and reduces flexibility. And as far as problems with filesystem tools, util-linux being a prime example, they ALREADY have problems with btrfs even WITH partitioning. I am in the process of discussing an issue right now on the util-linux list regarding failure of both umount and findmnt to properly handle btrfs volumes. Both EXPECT a btrfs volume to be on a single partition. On my system I currently have btrfs raid 1 volumes spread over up to 5 partitions on 5 different drives. mount handles this OK, but, in the case of umount, it will very often respond with "umount: LABEL=XXXX: not found. Using a debug statement suggested by Karel Zak demonstrates the problem. umount finds a device name matching one of the volumes, but it is not the mount point, thus umount is unable to verify that the volume is mounted (since it is searching the mount list for the wrong device) and fails. Same problem with findmnt. Its all a process over time, but they are just going to need to catch up and in the long run we will all benefit from that. Currently I have completely converted my main desktop to btrfs with everything except backup on raid 1 (I have one backup drive formatted JFS just in case!!!). I am extremely happy with it. My five 500GB system drives are conventionally partitioned. My 4TB backup drive is unpartioned formatted raw to btrfs. So I am getting experience with both and finding and working through the issues. Some time ago I had a problem deleting btrfs from a drive formatted raw without partitions, but later that got fixed and wipefs found the raw formatted btrfs remnants and successfully deleted them, leaving the drives in pristine shape and ready to be formatted for a new role in life. So we are getting there, its just going to take time. These of course only represent my opinions on the matter, I am sure not everyone will agree, and I fully accept that. - George -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html