btrfs on whole disk (no partitions)

btrfs on whole disk (no partitions)

[Daniel Cegiełka]

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

Re: btrfs on whole disk (no partitions)

[Chris Murphy]

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

Re: btrfs on whole disk (no partitions)

[Imran Geriskovan]

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

Re: btrfs on whole disk (no partitions)

[Russell Coker]

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/

Re: btrfs on whole disk (no partitions)

[George Mitchell]

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

Re: btrfs on whole disk (no partitions)

[Russell Coker]

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/

Re: btrfs on whole disk (no partitions)

[Imran Geriskovan]

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

Re: btrfs on whole disk (no partitions)

[Imran Geriskovan]

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

Re: btrfs on whole disk (no partitions)

[Austin S Hemmelgarn]

[-- 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 --]

Re: btrfs on whole disk (no partitions)

[Daniel Cegiełka]

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.

Re: btrfs on whole disk (no partitions)

[Daniel Cegiełka]

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.

Re: btrfs on whole disk (no partitions)

[Chris Murphy]

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

Re: btrfs on whole disk (no partitions)

[Chris Murphy]

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

Re: btrfs on whole disk (no partitions)

[Imran Geriskovan]

> 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

Re: btrfs on whole disk (no partitions)

[George Mitchell]

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.

Re: btrfs on whole disk (no partitions)

[Roman Mamedov]

[-- 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 --]

Re: btrfs on whole disk (no partitions)

[George Mitchell]

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.

Re: btrfs on whole disk (no partitions)

[George Mitchell]

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

Re: btrfs on whole disk (no partitions)

[Chris Murphy]

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

Re: btrfs on whole disk (no partitions)

[Chris Murphy]

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

Re: btrfs on whole disk (no partitions)

[Chris Murphy]

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

Re: btrfs on whole disk (no partitions)

[Duncan]

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

Re: btrfs on whole disk (no partitions)

[Martin K. Petersen]

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

Re: btrfs on whole disk (no partitions)

[Martin K. Petersen]

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

Re: btrfs on whole disk (no partitions)

[Duncan]

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

Re: btrfs on whole disk (no partitions)

[Imran Geriskovan]

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

Re: btrfs on whole disk (no partitions)

[Duncan]

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

Re: btrfs on whole disk (no partitions)

[Imran Geriskovan]

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

Re: btrfs on whole disk (no partitions)

[Chris Murphy]

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

Re: btrfs on whole disk (no partitions)

[Imran Geriskovan]

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