* Re: btrfs on whole disk (no partitions)
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
2014-06-18 21:19 ` Imran Geriskovan
` (2 subsequent siblings)
3 siblings, 1 reply; 30+ messages in thread
From: Chris Murphy @ 2014-06-18 20:10 UTC (permalink / raw)
To: Btrfs BTRFS, Daniel Cegiełka
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-18 20:10 ` Chris Murphy
@ 2014-06-19 11:15 ` Austin S Hemmelgarn
0 siblings, 0 replies; 30+ messages in thread
From: Austin S Hemmelgarn @ 2014-06-19 11:15 UTC (permalink / raw)
To: Chris Murphy, Btrfs BTRFS, Daniel Cegiełka
[-- 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 --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-18 19:29 btrfs on whole disk (no partitions) Daniel Cegiełka
2014-06-18 20:10 ` Chris Murphy
@ 2014-06-18 21:19 ` Imran Geriskovan
2014-06-19 0:07 ` Russell Coker
2014-06-19 1:01 ` George Mitchell
3 siblings, 0 replies; 30+ messages in thread
From: Imran Geriskovan @ 2014-06-18 21:19 UTC (permalink / raw)
To: Daniel Cegiełka; +Cc: linux-btrfs
On 6/18/14, Daniel Cegiełka <daniel.cegielka@gmail.com> wrote:
> I created btrfs directly to disk using such a scheme (no partitions):
> cd /mnt
> btrfs subvolume create __active
> btrfs subvolume create __active/rootvol
> 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.
Partitionless and subvolumeless desktop setup (everything is in
default subvolume) is operational here since kernel 3.10 (now 3.14).
No issues.
Regards, Imran
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-18 19:29 btrfs on whole disk (no partitions) Daniel Cegiełka
2014-06-18 20:10 ` Chris Murphy
2014-06-18 21:19 ` Imran Geriskovan
@ 2014-06-19 0:07 ` Russell Coker
2014-06-19 8:58 ` Imran Geriskovan
2014-06-21 19:12 ` Daniel Cegiełka
2014-06-19 1:01 ` George Mitchell
3 siblings, 2 replies; 30+ messages in thread
From: Russell Coker @ 2014-06-19 0:07 UTC (permalink / raw)
To: Daniel Cegiełka; +Cc: linux-btrfs
On Wed, 18 Jun 2014 21:29:39 Daniel Cegiełka wrote:
> 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.
For boot disks I use the traditional partitioning system. So far I don't run
any systems that have a boot disk larger than 2TB so I haven't needed to use
GPT.
I have a BTRFS RAID-1 on 2*3TB disks which have no partition tables, when the
filesystem is going to use the entire device and there's no boot loader there
is no reason to have a partition table.
I also have some SATA disks I use for backup which have no partition table
because one filesystem is going to use all the space.
If you don't need to have a boot loader or swap space on the disk then there's
no reason to have a partition table. Note that it's often good to have some
swap space even if everything can fit in RAM because Linux sometimes pages
things out to make more space for cache.
While it's possible to boot a system without a partition table are you going
to get a real benefit from that? Having a separate /boot filesystem may
"waste" 500M of disk space, but as it seems impossible to buy any new SATA
device smaller than a 60G SSD (and the 120G SSDs don't cost much more) is that
500M really an issue?
When a system fails to boot it's a major PITA and having an unusual boot setup
will make it much more difficult to Google for help if you boot in an unusual
way.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
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:12 ` Daniel Cegiełka
1 sibling, 1 reply; 30+ messages in thread
From: Imran Geriskovan @ 2014-06-19 8:58 UTC (permalink / raw)
To: linux-btrfs
On 6/19/14, Russell Coker <russell@coker.com.au> wrote:
> On Wed, 18 Jun 2014 21:29:39 Daniel Cegiełka wrote:
>> 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.
> If you don't need to have a boot loader or swap space on the disk
> then there's no reason to have a partition table. Note that it's often good
> to have some swap space even if everything can fit in RAM because
> Linux sometimes pages things out to make more space for cache.
Grub installs itself and boots from Partitionless Btrfs disk.
It is handy for straight forward installations.
However, you need boot partition (ie. initramfs and kernel to boot
from encrypted root) its another story.
Swap is an issue. But you may try zram (compressed ram swap).
I've got some crashes on 3.14. Thus, waiting for it to stabilize.
Imran
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-19 8:58 ` Imran Geriskovan
@ 2014-06-19 9:11 ` Imran Geriskovan
2014-06-21 19:19 ` Daniel Cegiełka
0 siblings, 1 reply; 30+ messages in thread
From: Imran Geriskovan @ 2014-06-19 9:11 UTC (permalink / raw)
To: linux-btrfs
On 6/19/14, Russell Coker <russell@coker.com.au> wrote:
> On Wed, 18 Jun 2014 21:29:39 Daniel Cegiełka wrote:
>> 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.
> If you don't need to have a boot loader or swap space on the disk
> then there's no reason to have a partition table. Note that it's often good
> to have some swap space even if everything can fit in RAM because
> Linux sometimes pages things out to make more space for cache.
Grub installs itself and boots from Partitionless Btrfs disk.
It is handy for straight forward installations.
However, IF you need boot partition (ie. initramfs and kernel to boot
from encrypted root) its another story.
Swap is an issue. But you may try zram (compressed ram swap).
I've got some crashes on 3.14. Thus, waiting for it to stabilize.
Imran
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-19 9:11 ` Imran Geriskovan
@ 2014-06-21 19:19 ` Daniel Cegiełka
2014-06-22 1:36 ` Chris Murphy
0 siblings, 1 reply; 30+ messages in thread
From: Daniel Cegiełka @ 2014-06-21 19:19 UTC (permalink / raw)
To: Imran Geriskovan; +Cc: linux-btrfs
2014-06-19 11:11 GMT+02:00 Imran Geriskovan <imran.geriskovan@gmail.com>:
> On 6/19/14, Russell Coker <russell@coker.com.au> wrote:
>
> Grub installs itself and boots from Partitionless Btrfs disk.
> It is handy for straight forward installations.
>
> However, IF you need boot partition (ie. initramfs and kernel to boot
> from encrypted root) its another story.
zfs "solved" this problem in grub (libzfs). I think we can find a
solution to work around this problem.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-21 19:19 ` Daniel Cegiełka
@ 2014-06-22 1:36 ` Chris Murphy
0 siblings, 0 replies; 30+ messages in thread
From: Chris Murphy @ 2014-06-22 1:36 UTC (permalink / raw)
To: Daniel Cegiełka; +Cc: Imran Geriskovan, linux-btrfs
On Jun 21, 2014, at 1:19 PM, Daniel Cegiełka <daniel.cegielka@gmail.com> wrote:
> 2014-06-19 11:11 GMT+02:00 Imran Geriskovan <imran.geriskovan@gmail.com>:
>> On 6/19/14, Russell Coker <russell@coker.com.au> wrote:
>
>>
>> Grub installs itself and boots from Partitionless Btrfs disk.
>> It is handy for straight forward installations.
>>
>> However, IF you need boot partition (ie. initramfs and kernel to boot
>> from encrypted root) its another story.
>
> zfs "solved" this problem in grub (libzfs). I think we can find a
> solution to work around this problem.
I don't know that this is a file system problem. There's some recent work being done in GRUB so that it's possible to use a dmcrypt+LUKS encrypted boot volume. Once that's working it shouldn't matter what the file system is.
Chris Murphy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-19 0:07 ` Russell Coker
2014-06-19 8:58 ` Imran Geriskovan
@ 2014-06-21 19:12 ` Daniel Cegiełka
2014-06-22 1:34 ` Chris Murphy
1 sibling, 1 reply; 30+ messages in thread
From: Daniel Cegiełka @ 2014-06-21 19:12 UTC (permalink / raw)
To: russell; +Cc: linux-btrfs
2014-06-19 2:07 GMT+02:00 Russell Coker <russell@coker.com.au>:
> For boot disks I use the traditional partitioning system. So far I don't run
> any systems that have a boot disk larger than 2TB so I haven't needed to use
> GPT.
>
> I have a BTRFS RAID-1 on 2*3TB disks which have no partition tables, when the
> filesystem is going to use the entire device and there's no boot loader there
> is no reason to have a partition table.
ok, but what about alignment? This can have a significant impact on performance.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-21 19:12 ` Daniel Cegiełka
@ 2014-06-22 1:34 ` Chris Murphy
2014-06-22 7:49 ` Imran Geriskovan
0 siblings, 1 reply; 30+ messages in thread
From: Chris Murphy @ 2014-06-22 1:34 UTC (permalink / raw)
To: Btrfs BTRFS
On Jun 21, 2014, at 1:12 PM, Daniel Cegiełka <daniel.cegielka@gmail.com> wrote:
> 2014-06-19 2:07 GMT+02:00 Russell Coker <russell@coker.com.au>:
>
>> For boot disks I use the traditional partitioning system. So far I don't run
>> any systems that have a boot disk larger than 2TB so I haven't needed to use
>> GPT.
>>
>> I have a BTRFS RAID-1 on 2*3TB disks which have no partition tables, when the
>> filesystem is going to use the entire device and there's no boot loader there
>> is no reason to have a partition table.
>
> ok, but what about alignment? This can have a significant impact on performance.
The 64KB Btrfs bootloader pad is 8 sector aligned, so for 512e AF disks there's no problem formatting the whole drive. The alignment problem actually happens when partitioning it, using old partition tools that don't align on 8 sector boundaries. There are some such tools still floating around.
Chris Murphy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-22 1:34 ` Chris Murphy
@ 2014-06-22 7:49 ` Imran Geriskovan
2014-06-22 13:44 ` George Mitchell
2014-06-22 18:31 ` Chris Murphy
0 siblings, 2 replies; 30+ messages in thread
From: Imran Geriskovan @ 2014-06-22 7:49 UTC (permalink / raw)
To: linux-btrfs
> The 64KB Btrfs bootloader pad is 8 sector aligned, so for 512e AF disks
> there's no problem formatting the whole drive. The alignment problem
> actually happens when partitioning it, using old partition tools that don't
> align on 8 sector boundaries. There are some such tools still floating
> around.
A 'somewhat' related question:
So called Advanced Format drives has 4K physical sector size,
however they report 512B logical sector size.
How does linux kernel access those drives?
512B or 4K at a time?
Imran
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-22 7:49 ` Imran Geriskovan
@ 2014-06-22 13:44 ` George Mitchell
2014-06-22 14:11 ` Roman Mamedov
2014-06-22 18:47 ` Chris Murphy
2014-06-22 18:31 ` Chris Murphy
1 sibling, 2 replies; 30+ messages in thread
From: George Mitchell @ 2014-06-22 13:44 UTC (permalink / raw)
To: linux-btrfs
On 06/22/2014 12:49 AM, Imran Geriskovan wrote:
>> The 64KB Btrfs bootloader pad is 8 sector aligned, so for 512e AF disks
>> there's no problem formatting the whole drive. The alignment problem
>> actually happens when partitioning it, using old partition tools that don't
>> align on 8 sector boundaries. There are some such tools still floating
>> around.
> A 'somewhat' related question:
>
> So called Advanced Format drives has 4K physical sector size,
> however they report 512B logical sector size.
>
> How does linux kernel access those drives?
> 512B or 4K at a time?
>
> Imran
> --
> 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
>
>
This is a problem related to Western Digital drives. They lie in order
to be compatible with older versions of Windows. Seagate AF drives
report 4K, not 512B. Western Digital took this path in order to make
the drives work with older Windows operating systems because Microsoft
chose not to include support for AF drives until the last minute. As
far as I know, btrfs defaults to 4K UNLESS you specify 512B when you
create the file system and the kernel follows the filesystem, not the
(in this case incorrect) info the drive reports, I could not find the
documentation to confirm this, perhaps someone else can confirm it.
Actually a 4K format will work just fine on a 512B drive AS LONG as the
alignment is correct. The larger problem occurs when a 4K drive is
formatted as 512B. But it is a real pain that the WD AF drives report
as being conventional drives in order to not confuse Windows.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
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:47 ` Chris Murphy
1 sibling, 2 replies; 30+ messages in thread
From: Roman Mamedov @ 2014-06-22 14:11 UTC (permalink / raw)
To: george; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]
On Sun, 22 Jun 2014 06:44:13 -0700
George Mitchell <george@chinilu.com> wrote:
> On 06/22/2014 12:49 AM, Imran Geriskovan wrote:
> >> The 64KB Btrfs bootloader pad is 8 sector aligned, so for 512e AF disks
> >> there's no problem formatting the whole drive. The alignment problem
> >> actually happens when partitioning it, using old partition tools that don't
> >> align on 8 sector boundaries. There are some such tools still floating
> >> around.
> > A 'somewhat' related question:
> >
> > So called Advanced Format drives has 4K physical sector size,
> > however they report 512B logical sector size.
> >
> > How does linux kernel access those drives?
> > 512B or 4K at a time?
>
> This is a problem related to Western Digital drives. They lie in order
> to be compatible with older versions of Windows.
Wake up and smell the coffee.
Device Model: HGST HTE725050A7E630
Sector Sizes: 512 bytes logical, 4096 bytes physical
Device Model: TOSHIBA DT01ACA050
Sector Sizes: 512 bytes logical, 4096 bytes physical
The "AF" standard as accepted by the industry does include this "lying", and
it's not just WD doing this by any stretch of the imagination. Aside from
USB-only drives (which lack the ability to be plugged into SATA), no one can
afford to produce and a drive incompatible with Windows these days. In fact
I'd be glad if you could support your Seagate 4K claim by any model names and
their smartctl output.
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-22 14:11 ` Roman Mamedov
@ 2014-06-22 14:41 ` George Mitchell
2014-06-22 14:46 ` George Mitchell
1 sibling, 0 replies; 30+ messages in thread
From: George Mitchell @ 2014-06-22 14:41 UTC (permalink / raw)
To: Roman Mamedov; +Cc: linux-btrfs
On 06/22/2014 07:11 AM, Roman Mamedov wrote:
> On Sun, 22 Jun 2014 06:44:13 -0700
> George Mitchell <george@chinilu.com> wrote:
>
>> On 06/22/2014 12:49 AM, Imran Geriskovan wrote:
>>>> The 64KB Btrfs bootloader pad is 8 sector aligned, so for 512e AF disks
>>>> there's no problem formatting the whole drive. The alignment problem
>>>> actually happens when partitioning it, using old partition tools that don't
>>>> align on 8 sector boundaries. There are some such tools still floating
>>>> around.
>>> A 'somewhat' related question:
>>>
>>> So called Advanced Format drives has 4K physical sector size,
>>> however they report 512B logical sector size.
>>>
>>> How does linux kernel access those drives?
>>> 512B or 4K at a time?
>> This is a problem related to Western Digital drives. They lie in order
>> to be compatible with older versions of Windows.
> Wake up and smell the coffee.
>
> Device Model: HGST HTE725050A7E630
> Sector Sizes: 512 bytes logical, 4096 bytes physical
>
>
> Device Model: TOSHIBA DT01ACA050
> Sector Sizes: 512 bytes logical, 4096 bytes physical
>
>
> The "AF" standard as accepted by the industry does include this "lying", and
> it's not just WD doing this by any stretch of the imagination. Aside from
> USB-only drives (which lack the ability to be plugged into SATA), no one can
> afford to produce and a drive incompatible with Windows these days. In fact
> I'd be glad if you could support your Seagate 4K claim by any model names and
> their smartctl output.
>
I am not sure I see anything wrong with that. They are showing a
physical block size of 4096. And it is the physical block size we care
about. As I recall Western Digital drives, at least in the beginning,
were reporting 512 physical. That was the problem.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
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
1 sibling, 1 reply; 30+ messages in thread
From: George Mitchell @ 2014-06-22 14:46 UTC (permalink / raw)
To: Roman Mamedov; +Cc: linux-btrfs
On 06/22/2014 07:11 AM, Roman Mamedov wrote:
> On Sun, 22 Jun 2014 06:44:13 -0700
> George Mitchell <george@chinilu.com> wrote:
>
>> On 06/22/2014 12:49 AM, Imran Geriskovan wrote:
>>>> The 64KB Btrfs bootloader pad is 8 sector aligned, so for 512e AF disks
>>>> there's no problem formatting the whole drive. The alignment problem
>>>> actually happens when partitioning it, using old partition tools that don't
>>>> align on 8 sector boundaries. There are some such tools still floating
>>>> around.
>>> A 'somewhat' related question:
>>>
>>> So called Advanced Format drives has 4K physical sector size,
>>> however they report 512B logical sector size.
>>>
>>> How does linux kernel access those drives?
>>> 512B or 4K at a time?
>> This is a problem related to Western Digital drives. They lie in order
>> to be compatible with older versions of Windows.
> Wake up and smell the coffee.
>
> Device Model: HGST HTE725050A7E630
> Sector Sizes: 512 bytes logical, 4096 bytes physical
>
>
> Device Model: TOSHIBA DT01ACA050
> Sector Sizes: 512 bytes logical, 4096 bytes physical
>
>
> The "AF" standard as accepted by the industry does include this "lying", and
> it's not just WD doing this by any stretch of the imagination. Aside from
> USB-only drives (which lack the ability to be plugged into SATA), no one can
> afford to produce and a drive incompatible with Windows these days. In fact
> I'd be glad if you could support your Seagate 4K claim by any model names and
> their smartctl output.
>
Here is the story:
http://johannes-bauer.com/linux/wdc/?menuid=3
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-22 14:46 ` George Mitchell
@ 2014-06-22 18:56 ` Chris Murphy
0 siblings, 0 replies; 30+ messages in thread
From: Chris Murphy @ 2014-06-22 18:56 UTC (permalink / raw)
To: Btrfs BTRFS
On Jun 22, 2014, at 8:46 AM, George Mitchell <george@chinilu.com> wrote:
>
> http://johannes-bauer.com/linux/wdc/?menuid=3
OK well a post full of hyperbole from an misogynistic jackass doesn't really convince me there's a real problem here. Telling Linux/fdisk/parted that a 4096 byte physical sector drive is 512 byte physical sector doesn't cause any change in behavior regarding alignment. Alignment is done by starting each partition at an LBA that's 8 sector aligned. This has been done for quite a long time on Linux by starting partition 1 at LBA 2048 which is not merely 8 sector aligned but is 1MB aligned. And further by specifying partition sizes in whole MB is both easy and assures alignment for any subsequent partitions. It makes no difference if the drive is 512/512 or 512/4096.
What might matter is if the Linux SCSI layer is optimizing writes to 512/512 drives, where a 4096 byte file system block doesn't need to be completely rewritten, rather only fewer than all 8 sectors. So if the Linux SCSI layer does that on a 4096 byte physical sector drive, it will cause the drive to do RMW. So either someone familiar with the code maybe will speak up how this works, or how to find out indirectly by intercepting commands to the drive.
Chris Murphy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-22 13:44 ` George Mitchell
2014-06-22 14:11 ` Roman Mamedov
@ 2014-06-22 18:47 ` Chris Murphy
2014-06-23 2:10 ` Duncan
1 sibling, 1 reply; 30+ messages in thread
From: Chris Murphy @ 2014-06-22 18:47 UTC (permalink / raw)
To: Btrfs BTRFS
On Jun 22, 2014, at 7:44 AM, George Mitchell <george@chinilu.com> wrote:
> This is a problem related to Western Digital drives. They lie in order to be compatible with older versions of Windows. Seagate AF drives report 4K, not 512B. Western Digital took this path in order to make the drives work with older Windows operating systems because Microsoft chose not to include support for AF drives until the last minute.
What a number of drive manufacturers did was have a Windows XP jumper setting which caused a +1 offset to all LBAs. That is, with the juper set the on-disk LBA 0 would not get used, an OS request of LBA 0 actually accessed LBA 1. What this did was it caused partition 1, which on XP and older starts at LBA 63, to actually start on disk at LBA 64 which is 8 sector aligned. This resolved the alignment problem for XP but then would cause an alignment problem if used with a partition tool that properly aligned, which is why it had to be unset for those systems.
Merely having a drive report physical sector size of 512 does not solve the alignment problem with AF disks so I don't know why any drive manufacturer would be motivated to do this. But then, many of us have SSDs which we know do not have such a thing as a physical sector, the closest structure that comes to that is maybe the page, and this varies among models maybe the most common being 4096 bytes but some write ups have said they are up to 16KB. Yet all SSD's report physical sector size of 512 bytes.
> As far as I know, btrfs defaults to 4K UNLESS you specify 512B
I'm not sure what this means. The Btrfs sector size minimum is 4096 bytes. I can use -s to make it bigger, but not less than 4096 on 512/512 or 512/4096 byte drives. I actually don't know what Btrfs sector size is but it's not the same thing as drive logical or physical sector size.
Chris Murphy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-22 18:47 ` Chris Murphy
@ 2014-06-23 2:10 ` Duncan
2014-06-23 12:24 ` Martin K. Petersen
0 siblings, 1 reply; 30+ messages in thread
From: Duncan @ 2014-06-23 2:10 UTC (permalink / raw)
To: linux-btrfs
Chris Murphy posted on Sun, 22 Jun 2014 12:47:10 -0600 as excerpted:
>> As far as I know, btrfs defaults to 4K UNLESS you specify 512B
>
> I'm not sure what this means. The Btrfs sector size minimum is 4096
> bytes.
> I can use -s to make it bigger, but not less than 4096 on 512/512 or
> 512/4096 byte drives. I actually don't know what Btrfs sector size is
> but it's not the same thing as drive logical or physical sector size.
FWIW, for btrfs I prefer the terms block size or page size, which on x86
(both 32-bit and 64-bit) and arm is 4096 bytes (tho on other archs it can
range from 2048 byte to 64 KiB), reserving the "sector" term for actual
hardware.
Btrfs is copy-on-write, and AFAIK sends no operations to the lower levels
at smaller than this block size, so on x86 (32-bit or 64-bit), all btrfs
level operations should be in 4096-byte increments, regardless of the
underlying ATA/SCSI hardware.
Tho as you point out elsewhere, levels under the filesystem layer may
split the btrfs 4096 byte block size into 512 byte logical sector sizes
if appropriate, but that has nothing to do with btrfs except that it
operates on top of that.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
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
0 siblings, 2 replies; 30+ messages in thread
From: Martin K. Petersen @ 2014-06-23 12:24 UTC (permalink / raw)
To: Duncan; +Cc: linux-btrfs
>>>>> "Duncan" == Duncan <1i5t5.duncan@cox.net> writes:
Duncan> Tho as you point out elsewhere, levels under the filesystem
Duncan> layer may split the btrfs 4096 byte block size into 512 byte
Duncan> logical sector sizes if appropriate, but that has nothing to do
Duncan> with btrfs except that it operates on top of that.
The notion of "splitting into a different block size" is a bit
confusing. The filesystem submits an N-byte I/O. Whether the logical
block size is 512 or 4096 doesn't really matter. We're still
transferring N bytes of data. The only thing the logical block size
really affects is how we calculate the LBA and block counts in the
command we send to the device. If N is not a multiple of the device's
logical block size we'll simply reject the I/O. If we receive an I/O
that is misaligned or not a multiple of the physical block size we let
the drive do RMW. So there isn't any "splitting" going on.
An I/O may be split if MD or DM is involved and the request straddles a
stripe chunk boundary. Because Linux generally does all I/O in terms of
4K pages, sub-page size splits are rare. Pretty much all the other cases
that would force us to split an I/O (typically controller DMA
constraints) operate on a page boundary.
To avoid the drive being forced to do RMW on the head and tail of a
misaligned I/O it is imperative that the filesystems are aligned to the
physical block size of the underlying device. As has been pointed out
the partitioning utilities generally make sure that's the case. If there
are no partitions then you're by definition aligned unless the drive has
the infamous Windows XP jumper installed.
Anyway. The short answer is that Linux will pretty much always do I/O in
multiples of the system page size regardless of the logical block size
of the underlying device. There are a few exceptions to this such as
direct I/O, legacy filesystems using bufferheads and raw block device
access.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-23 12:24 ` Martin K. Petersen
@ 2014-06-24 5:37 ` Duncan
2014-06-25 13:01 ` Imran Geriskovan
1 sibling, 0 replies; 30+ messages in thread
From: Duncan @ 2014-06-24 5:37 UTC (permalink / raw)
To: linux-btrfs
Martin K. Petersen posted on Mon, 23 Jun 2014 08:24:04 -0400 as excerpted:
> Anyway. The short answer is that Linux will pretty much always do I/O in
> multiples of the system page size regardless of the logical block size
> of the underlying device. There are a few exceptions to this such as
> direct I/O, legacy filesystems using bufferheads and raw block device
> access.
Thank you. Good to have that made clear. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
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:41 ` Chris Murphy
1 sibling, 2 replies; 30+ messages in thread
From: Imran Geriskovan @ 2014-06-25 13:01 UTC (permalink / raw)
To: linux-btrfs
On 6/23/14, Martin K. Petersen <martin.petersen@oracle.com> wrote:
> Anyway. The short answer is that Linux will pretty much always do I/O in
> multiples of the system page size regardless of the logical block size
> of the underlying device. There are a few exceptions to this such as
> direct I/O, legacy filesystems using bufferheads and raw block device
> access.
Thanks for the clarification.
And some random notes:
Note that gdisk gives default 8 sector alignment value for AF disks.
That is 'sector' meant by gdisk is 'Logical Sector'!
Sufficiently determined user may create misaligned
partitions by playing with alignment value and partition start/end
values.
There are SSDs with 4K, 8K block/page sizes and
512K, 1M, 1.5M Erase block sizes.
Partitions should be aligned with Erase blocks.
And filesystem block size (leafsize for btrfs. Default 16 K)
should be in multiples of device block size.
Regards, Imran
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
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
1 sibling, 1 reply; 30+ messages in thread
From: Duncan @ 2014-06-25 16:01 UTC (permalink / raw)
To: linux-btrfs
Imran Geriskovan posted on Wed, 25 Jun 2014 15:01:49 +0200 as excerpted:
> Note that gdisk gives default 8 sector alignment value for AF disks.
> That is 'sector' meant by gdisk is 'Logical Sector'!
> Sufficiently determined user may create misaligned partitions by playing
> with alignment value and partition start/end values.
AFAIK, for gdisk it's actually 2048 sector (1 MiB) alignment by default,
on new devices or if you clear and redo the entire partition table. On
pre-partitioned devices, gdisk will attempt to identify current
alignment, but will set 8-sector alignment on devices > 300 GiB even
where previous alignment vales are less than that. See the gdisk manpage
under the "l" option for more.
The same applies to cgdisk (under the Align option in its manpage).
This has been the documented gdisk behavior for some versions now (I've
been using it for awhile and remember when the default behavior changed),
altho I'm referring to the 0.8.10 manpages for the version I have
installed right now.
Tho here, I started my first partition, the BIOS boot partition, at 1 MiB
and made it 3 MiB in size, so it ends at 4 MiB, with everything beyond
that 4 MiB aligned. The second partition is the EFI system partition,
124 MiB in size so ending at 128 MiB, with everything beyond that 128 MiB
aligned. The next partition is /boot, 256 MiB, followed by a 640 MiB
/var/log, ending at 1 GiB, with everything beyond that aligned on GiB
boundaries.
That makes for easier reconstruction should I lose both copies of the GPT
partition table. Plus, as Linus says, "real men" publish it on the net
and then use the net for backup, and I've posted my partition table
several times, so if I need to I can just look it up in my postings right
here. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-25 16:01 ` Duncan
@ 2014-06-26 18:26 ` Imran Geriskovan
0 siblings, 0 replies; 30+ messages in thread
From: Imran Geriskovan @ 2014-06-26 18:26 UTC (permalink / raw)
To: Duncan; +Cc: linux-btrfs
On 6/25/14, Duncan <1i5t5.duncan@cox.net> wrote:
> Imran Geriskovan posted on Wed, 25 Jun 2014 15:01:49 +0200 as excerpted:
>> Note that gdisk gives default 8 sector alignment value for AF disks.
>> That is 'sector' meant by gdisk is 'Logical Sector'!
>> Sufficiently determined user may create misaligned partitions by playing
>> with alignment value and partition start/end values.
> AFAIK, for gdisk it's actually 2048 sector (1 MiB) alignment by default,
> on new devices or if you clear and redo the entire partition table.
Alignment does not mean starting your partition on 2048.
It means aligning partitions with physical block boundries.
By default cgdisk chooses 2048 sector as the start of first partition.
However you can use 32 - 2047 as well. (i.e. for Bios_Boot partition)
"Alignment value of 8" contraints your choices of partition locations
such as Sector 32, 40, 48,... so forth.. (in increments of 4K which
corresponds one physical block).
Regards, Imran
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-25 13:01 ` Imran Geriskovan
2014-06-25 16:01 ` Duncan
@ 2014-06-26 18:41 ` Chris Murphy
2014-06-26 20:46 ` Imran Geriskovan
1 sibling, 1 reply; 30+ messages in thread
From: Chris Murphy @ 2014-06-26 18:41 UTC (permalink / raw)
To: Btrfs BTRFS
On Jun 25, 2014, at 7:01 AM, Imran Geriskovan <imran.geriskovan@gmail.com> wrote:
> On 6/23/14, Martin K. Petersen <martin.petersen@oracle.com> wrote:
>> Anyway. The short answer is that Linux will pretty much always do I/O in
>> multiples of the system page size regardless of the logical block size
>> of the underlying device. There are a few exceptions to this such as
>> direct I/O, legacy filesystems using bufferheads and raw block device
>> access.
>
> Thanks for the clarification.
>
> And some random notes:
>
> Note that gdisk gives default 8 sector alignment value for AF disks.
> That is 'sector' meant by gdisk is 'Logical Sector'!
> Sufficiently determined user may create misaligned
> partitions by playing with alignment value and partition start/end
> values.
>
> There are SSDs with 4K, 8K block/page sizes and
> 512K, 1M, 1.5M Erase block sizes.
>
> Partitions should be aligned with Erase blocks.
>
That sounds plausible, but the FTL in the consumer SSD's most all of us are buying isn't going to give you any assurance it's actually writing with such boundaries in mind. You may have partition 1 start on LBA 2048, which is 1MB aligned, but as soon as you're writing data to LBA 2048 through say LBA 2560, for all you know that write actually ends up in pages that are located in the first and second erase blocks; or maybe all of it's in the 8th erase block. The OS side of things we don't have insight or control over this.
Also these days parted, fdisk and gdisk should all be starting partition 1 at LBA 2048, 1MB aligned. Some differences come into play with 4096/4096 logical/physical sector drives, but so far I've only seen this as the result of USB enclosures. I haven't seen 4Kn AF bare drives in the wild thus far.
Chris Murphy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-26 18:41 ` Chris Murphy
@ 2014-06-26 20:46 ` Imran Geriskovan
0 siblings, 0 replies; 30+ messages in thread
From: Imran Geriskovan @ 2014-06-26 20:46 UTC (permalink / raw)
To: Chris Murphy; +Cc: Btrfs BTRFS
On 6/26/14, Chris Murphy <lists@colorremedies.com> wrote:
> On Jun 25, 2014, at 7:01 AM, Imran Geriskovan <imran.geriskovan@gmail.com>
>> There are SSDs with 4K, 8K block/page sizes and
>> 512K, 1M, 1.5M Erase block sizes.
>> Partitions should be aligned with Erase blocks.
> That sounds plausible, but the FTL in the consumer SSD's most all of us are
> buying isn't going to give you any assurance it's actually writing with such
> boundaries in mind. You may have partition 1 start on LBA 2048, which is 1MB
> aligned, but as soon as you're writing data to LBA 2048 through say LBA
> 2560, for all you know that write actually ends up in pages that are located
> in the first and second erase blocks; or maybe all of it's in the 8th erase
> block. The OS side of things we don't have insight or control over this.
8 Logical blocks (Not 8 Erase blocks) makes a 4K Physical block.
(a) Basic principle is to align with "Physical blocks" ("Pages" for SSDs).
(b) For SSDs, aligning with Erase blocks (512K, 1M, 1.5M) also satisfy (a)
Regards, Imran
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-22 7:49 ` Imran Geriskovan
2014-06-22 13:44 ` George Mitchell
@ 2014-06-22 18:31 ` Chris Murphy
2014-06-23 11:34 ` Martin K. Petersen
1 sibling, 1 reply; 30+ messages in thread
From: Chris Murphy @ 2014-06-22 18:31 UTC (permalink / raw)
To: Btrfs BTRFS
On Jun 22, 2014, at 1:49 AM, Imran Geriskovan <imran.geriskovan@gmail.com> wrote:
>> The 64KB Btrfs bootloader pad is 8 sector aligned, so for 512e AF disks
>> there's no problem formatting the whole drive. The alignment problem
>> actually happens when partitioning it, using old partition tools that don't
>> align on 8 sector boundaries. There are some such tools still floating
>> around.
>
> A 'somewhat' related question:
>
> So called Advanced Format drives has 4K physical sector size,
> however they report 512B logical sector size.
>
> How does linux kernel access those drives?
> 512B or 4K at a time?
Does anyone know if blktrace will intercept the actual SCSI commands sent to the drive? Or is there a better utility to use for this? When I use it unfiltered, I'm not seeing SCSI write commands at all.
This is the blktrace/blkparse for dd if=/dev/zero of=/dev/sda seek=430234064 count=8 oflag=direct
https://docs.google.com/file/d/0B_2Asp8DGjJ9c3J0UXpzUEhNaGs/edit?pli=1
This is the blktrace/blkparse for dd if=/dev/zero of=/dev/sda bs=4096 seek=53779258 count=1
https://docs.google.com/file/d/0B_2Asp8DGjJ9MnEwU0hDNE45dHc/edit?pli=1
The dd command clearly shows a difference, but when I look at the ATA command set I'd expect the Linux SCSI layer to turn these dd commands into the same ATA command: basically a write start LBA and sector count. And the LBA and sector count can only be in 512 byte sector addresses because that's all a 512e type of AF disk understands.
Chris Murphy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-22 18:31 ` Chris Murphy
@ 2014-06-23 11:34 ` Martin K. Petersen
0 siblings, 0 replies; 30+ messages in thread
From: Martin K. Petersen @ 2014-06-23 11:34 UTC (permalink / raw)
To: Chris Murphy; +Cc: Btrfs BTRFS
>>>>> "Chris" == Chris Murphy <lists@colorremedies.com> writes:
Chris> Does anyone know if blktrace will intercept the actual SCSI
Chris> commands sent to the drive? Or is there a better utility to use
Chris> for this? When I use it unfiltered, I'm not seeing SCSI write
Chris> commands at all.
# echo scsi:scsi_dispatch_cmd_start > /sys/kernel/debug/tracing/set_event
# echo 1 > /sys/kernel/debug/tracing/tracing_on
[do stuff]
# cat /sys/kernel/debug/tracing/trace
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-18 19:29 btrfs on whole disk (no partitions) Daniel Cegiełka
` (2 preceding siblings ...)
2014-06-19 0:07 ` Russell Coker
@ 2014-06-19 1:01 ` George Mitchell
2014-06-19 4:52 ` Russell Coker
3 siblings, 1 reply; 30+ messages in thread
From: George Mitchell @ 2014-06-19 1:01 UTC (permalink / raw)
To: linux-btrfs
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). That is one of
the frustrating side effects I have noticed with a non-partitioned 4TB
drive on 32bit dual core pentium system. 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. 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.
On 06/18/2014 12:29 PM, Daniel Cegiełka 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
>
> 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.
>
> I will be grateful for your feedback.
> Best regards,
> Daniel
> --
> 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
>
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: btrfs on whole disk (no partitions)
2014-06-19 1:01 ` George Mitchell
@ 2014-06-19 4:52 ` Russell Coker
0 siblings, 0 replies; 30+ messages in thread
From: Russell Coker @ 2014-06-19 4:52 UTC (permalink / raw)
To: george; +Cc: linux-btrfs
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/
^ permalink raw reply [flat|nested] 30+ messages in thread