Re: BTRFS, SSD and single metadata

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

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

On 2014-06-16 07:18, Swâmi Petaramesh wrote:
> Hi Austin, and thanks for your reply.
> 
> Le lundi 16 juin 2014, 07:09:55 Austin S Hemmelgarn a écrit :
>>
>> What mkfs.btrfs looks at is
>> /sys/block/<whatever-device>/queue/rotational, if that is 1 it knows
>> that the device isn't a SSD.  I believe that LVM passes through whatever
>> the next lower layer's value is, but dmcrypt (and by extension LUKS)
>> always force it to a 1 (possibly to prevent programs from using
>> heuristics for enabling discard)
> 
> In the current "running condition", the system clearly sees this is *not* 
> rotational, even thru the LVM/dmcrypt stack :
> 
> # mount | grep btrfs
> /dev/mapper/VG-LINUX on / type btrfs 
> (rw,noatime,seclabel,compress=lzo,ssd,discard,space_cache,autodefrag)
> 
> # ll /dev/mapper/VGV-LINUX
> lrwxrwxrwx. 1 root root 7 16 juin  09:21 /dev/mapper/VG-LINUX -> ../dm-1
> 
> # cat /sys/block/dm-1/queue/rotational 
> 0
> 
> ...However, at mkfs.btrfs time, it migth well not have seen it, as I made it 
> from a live USB key in which both the lvm.conf and crypttab had not been 
> taylored to allow "trim" commands...
> 
> However, now that the FS is created, I still wonder whether I should use a 
> rebalance to change the metadata from DUP to SINGLE, or if Id' better stay 
> with DUP...
> 
> Kind regards.
> 
> 
I'd personally stay with the DUP profile, but then that's just me being
paranoid.  You will almost certainly get better performance using the
SINGLE profile instead of DUP, but this is mostly due to it requiring
fewer blocks to be encrypted by LUKS (Which is almost certainly your
primary bottleneck unless you have some high-end crypto-accelerator card).


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