Best Practice - Partition, or not?

Best Practice - Partition, or not?

[Alexander Skwar]

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

Re: Best Practice - Partition, or not?

[dima]

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)

Re: Best Practice - Partition, or not?

[Alexander Skwar]

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

Re: Best Practice - Partition, or not?

[Russell Coker]

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/

Re: Best Practice - Partition, or not?

[dima]

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)

Re: Best Practice - Partition, or not?

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

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. ---                 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Best Practice - Partition, or not?

[Helmut Hullen]

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

Re: Best Practice - Partition, or not?

[Kai Krakow]

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

Re: Best Practice - Partition, or not?

[George Mitchell]

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

Re: Best Practice - Partition, or not?

[Gabriel de Perthuis]

> 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.