linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: "Chris Murphy" <lists@colorremedies.com>,
	"Btrfs BTRFS" <linux-btrfs@vger.kernel.org>,
	"Daniel Cegiełka" <daniel.cegielka@gmail.com>
Subject: Re: btrfs on whole disk (no partitions)
Date: Thu, 19 Jun 2014 07:15:29 -0400	[thread overview]
Message-ID: <53A2C651.5080907@gmail.com> (raw)
In-Reply-To: <33D49915-811C-459F-B221-3F342F6D4944@colorremedies.com>

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

On 2014-06-18 16:10, Chris Murphy wrote:
> 
> On Jun 18, 2014, at 1:29 PM, Daniel Cegiełka <daniel.cegielka@gmail.com> wrote:
> 
>> Hi,
>> I created btrfs directly to disk using such a scheme (no partitions):
>>
>> dd if=/dev/zero of=/dev/sda bs=4096
>> mkfs.btrfs -L dev_sda /dev/sda
>> mount /dev/sda /mnt
>>
>> cd /mnt
>> btrfs subvolume create __active
>> btrfs subvolume create __active/rootvol
>> btrfs subvolume create __active/usr
>> btrfs subvolume create __active/home
>> btrfs subvolume create __active/var
>> btrfs subvolume create __snapshots
>>
>> cd /
>> umount /mnt
>> mount -o subvol=__active/rootvol /dev/sda /mnt
>> mkdir /mnt/{usr,home,var}
>> mount -o subvol=__active/usr /dev/sda /mnt/usr
>> mount -o subvol=__active/home /dev/sda /mnt/home
>> mount -o subvol=__active/var /dev/sda /mnt/var
>>
>> # /etc/fstab
>> UID=ID    /    btrfs rw,relative,space_cache,subvol=__active/rootvol    0 0
>> UUID=ID    /usr    btrfs rw,relative,space_cache,subvol=__active/usr    0 0
>> UUID=ID    /home    btrfs rw,relative,space_cache,subvol=__active/home    0 0
>> UUID=ID    /var    btrfs rw,relative,space_cache,subvol=__active/var    0 0
> 
> rw and space_cache are redundant because they are default; and relative is not a valid mount option. All you need is subvol= 
> 
>> Everything works fine. Is such a solution is recommended? In my
>> opinion, the creation of the partitions seems to be completely
>> unnecessary if you can use btrfs.
> 
> It's firmware specific. Some BIOS firmwares will want to see a valid MBR partition map at LBA 0, not just boot code. Others only care to blindly execute the boot code which would be put in the Btrfs bootloader pad (64KB). I don't know if parted 3.1 recognizes partitionless disks with Btrfs though so it might slightly increase the risk that it's treated as something other than what it is.
> 
> For UEFI firmware, it would definitely need to be partitioned since an EFI System partition is required.
> 
> Chris Murphy--
> 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 most hardware, I would definitely suggest at least adding a minimal
sized partition table, the people who design the BIOS code on most
systems make too many assumptions to trust their code to work correctly.
 That said, I regularly use BTRFS on flat devices for the root
filesystems for Xen PV Guest systems, systems that boot from SAN, and
secondary disks on other systems with no issues whatsoever.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]

  reply	other threads:[~2014-06-19 11:16 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-18 19:29 btrfs on whole disk (no partitions) Daniel Cegiełka
2014-06-18 20:10 ` Chris Murphy
2014-06-19 11:15   ` Austin S Hemmelgarn [this message]
2014-06-18 21:19 ` Imran Geriskovan
2014-06-19  0:07 ` Russell Coker
2014-06-19  8:58   ` Imran Geriskovan
2014-06-19  9:11     ` Imran Geriskovan
2014-06-21 19:19       ` Daniel Cegiełka
2014-06-22  1:36         ` Chris Murphy
2014-06-21 19:12   ` Daniel Cegiełka
2014-06-22  1:34     ` Chris Murphy
2014-06-22  7:49       ` Imran Geriskovan
2014-06-22 13:44         ` George Mitchell
2014-06-22 14:11           ` Roman Mamedov
2014-06-22 14:41             ` George Mitchell
2014-06-22 14:46             ` George Mitchell
2014-06-22 18:56               ` Chris Murphy
2014-06-22 18:47           ` Chris Murphy
2014-06-23  2:10             ` Duncan
2014-06-23 12:24               ` Martin K. Petersen
2014-06-24  5:37                 ` Duncan
2014-06-25 13:01                 ` Imran Geriskovan
2014-06-25 16:01                   ` Duncan
2014-06-26 18:26                     ` Imran Geriskovan
2014-06-26 18:41                   ` Chris Murphy
2014-06-26 20:46                     ` Imran Geriskovan
2014-06-22 18:31         ` Chris Murphy
2014-06-23 11:34           ` Martin K. Petersen
2014-06-19  1:01 ` George Mitchell
2014-06-19  4:52   ` Russell Coker

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=53A2C651.5080907@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=daniel.cegielka@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    /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;
as well as URLs for NNTP newsgroup(s).