Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: George Mitchell <george@chinilu.com>
To: Kai Krakow <hurikhan77+btrfs@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Best Practice - Partition, or not?
Date: Wed, 08 May 2013 09:58:03 -0700	[thread overview]
Message-ID: <518A841B.1090205@chinilu.com> (raw)
In-Reply-To: <njbp5a-7tq.ln1@hurikhan.ath.cx>

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

  reply	other threads:[~2013-05-08 16:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-01  7:51 Best Practice - Partition, or not? Alexander Skwar
2013-05-01  7:59 ` dima
2013-05-01  8:37   ` Alexander Skwar
2013-05-01  8:44   ` Russell Coker
2013-05-01  8:50     ` dima
2013-05-01  8:00 ` Hugo Mills
2013-05-01  8:46 ` Helmut Hullen
2013-05-08  7:31   ` Kai Krakow
2013-05-08 16:58     ` George Mitchell [this message]
2013-05-01  9:16 ` Gabriel de Perthuis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=518A841B.1090205@chinilu.com \
    --to=george@chinilu.com \
    --cc=hurikhan77+btrfs@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox