mkfs.btrfs doesn't detect SSD

mkfs.btrfs doesn't detect SSD

[Christoph Anton Mitterer]

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

Hey.

I'm creating a filesystem on Samsung Evo 850 Pro on top of a dm-
crypt/LUKS container (with TRIM not being passed on, for the usual
security reasons):
# mkfs.btrfs --label system /dev/mapper/system 
btrfs-progs v4.2.2
See http://btrfs.wiki.kernel.org for more information.

Label:              system
UUID:               65531196-2e43-4c49-b495-ac9abc57d7d8
Node size:          16384
Sector size:        4096
Filesystem size:    937.00GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         DUP               1.01GiB
  System:           DUP              12.00MiB
SSD detected:       no
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
   ID        SIZE  PATH
    1   937.00GiB  /dev/mapper/system


As you can see it doesn't detect the SSD.
Isn't that kinda problematic cause btrfs does more when it detects and
SSD than just using TRIM (e.g. not DUPing meta-data)?

Can I somehow override this to get the SSD "detected"?
Or what is the general suggestion here? Having it handled as SSD or as
non-SSD, as said, when dm-crypt is used below and TRIM is not intended
to be used.


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]

Re: mkfs.btrfs doesn't detect SSD

[Chris Murphy]

On Sat, Nov 7, 2015 at 4:05 PM, Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
> Hey.
>
> I'm creating a filesystem on Samsung Evo 850 Pro on top of a dm-
> crypt/LUKS container (with TRIM not being passed on, for the usual
> security reasons):
> # mkfs.btrfs --label system /dev/mapper/system
> btrfs-progs v4.2.2
> See http://btrfs.wiki.kernel.org for more information.
>
> Label:              system
> UUID:               65531196-2e43-4c49-b495-ac9abc57d7d8
> Node size:          16384
> Sector size:        4096
> Filesystem size:    937.00GiB
> Block group profiles:
>   Data:             single            8.00MiB
>   Metadata:         DUP               1.01GiB
>   System:           DUP              12.00MiB
> SSD detected:       no
> Incompat features:  extref, skinny-metadata
> Number of devices:  1
> Devices:
>    ID        SIZE  PATH
>     1   937.00GiB  /dev/mapper/system
>
>
> As you can see it doesn't detect the SSD.
> Isn't that kinda problematic cause btrfs does more when it detects and
> SSD than just using TRIM (e.g. not DUPing meta-data)?
>
> Can I somehow override this to get the SSD "detected"?
> Or what is the general suggestion here? Having it handled as SSD or as
> non-SSD, as said, when dm-crypt is used below and TRIM is not intended
> to be used.

There are three separate SSD related optimizations:

Allocation optimization is the mount time -o ssd and ssd_spread
options; which on dmcrypt devices you'll need to manually add because
the fact this is an SSD isn't passed through the device mapper
apparently.

Using single instead of duplicate metadata is a mkfs time option,
probably uses the same detection method as mount time allocation
optimization, and why you get DUP instead of single. So you have to
mkfs manually or use 'btrfs balance -mconvert=single -f' to force
changing it, forcing is required since a reduction in redunancy will
happen.

Trim, isn't used automatically, it's a mount time option, -o discard.



-- 
Chris Murphy

Re: mkfs.btrfs doesn't detect SSD

[Christoph Anton Mitterer]

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

Hmm in fact it seems to be the kernel who wrongly, detects the type:
/sys/block/sdb/queue/rotational = 1
or more like the USB/SATA bridge simply reports it wrong.

Anyway, is there a way to override? Or will setting
/sys/block/sdb/queue/rotational = 0 give the expected behaviour?


Thanks,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]

Re: mkfs.btrfs doesn't detect SSD

[Austin S Hemmelgarn]

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

On 2015-11-07 10:30, Christoph Anton Mitterer wrote:
> Hmm in fact it seems to be the kernel who wrongly, detects the type:
> /sys/block/sdb/queue/rotational = 1
> or more like the USB/SATA bridge simply reports it wrong.
>
> Anyway, is there a way to override? Or will setting
> /sys/block/sdb/queue/rotational = 0 give the expected behaviour?
This is a common issue with many USB/SATA bridges (and also 
device-mapper and MD devices), which don't properly query the attached 
device and modify the properties they report to the host system.  If you 
have some way to reliably identify this particular device, you could add 
a udev rule to automatically set it as non-rotational.  You could also 
do like you suggested and set it to non-rotational manually, although 
for mkfs at least, it's quicker to just manually specify '-m single'  on 
the command-line (that's the only difference in mkfs behavior for a 
SSD).  Like Chris said in his reply though, everything other than using 
single profile for metadata is done at mount time (if queue/rotational 
is 0, then -o ssd does get added to the mount options automatically, but 
it's a lot clearer to just specify the option yourself).


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