ssd not detected on ssd drive

ssd not detected on ssd drive

[covici]

Hi.  I was making a few file systems on my ssd drives (using lvm on top)
and noticed that the ssd was not detected.  The only thing that happened
is that the metadata is duplicated.  Is this a problem, or a waste of
space?  If I wanted to remake the file systems -- which I don't want to
do unless necessary -- how would I prevent this?

Thanks in advance for any suggestions.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: ssd not detected on ssd drive

[Duncan]

covici posted on Thu, 24 Dec 2015 05:56:22 -0500 as excerpted:

> Hi.  I was making a few file systems on my ssd drives (using lvm on top)
> and noticed that the ssd was not detected.  The only thing that happened
> is that the metadata is duplicated.  Is this a problem, or a waste of
> space?  If I wanted to remake the file systems -- which I don't want to
> do unless necessary -- how would I prevent this?

SSD detection is based on the value of "rotational" for the device as 
listed in sysfs.  Some virtual-block-device layers aren't transparent in 
this regard and don't reflect the value of the lower levels upward to the 
next.  It would seem lvm is one such non-transparent layer.

Of course you could manually set the rotational value in sysfs yourself, 
or you could create a udev rule to do it for you, but there's really no 
need, as all btrfs does with the value is automatically set some options 
you can already specify directly, and specifying them directly at the 
btrfs level is generally easier and more reliable anyway.

For mkfs.btrfs, the only thing ssd detection does is change the single-
device-btrfs metadata default from its normal dup mode to single, and 
since you can already specify which you want using the -m option, it's no 
big deal.

At runtime, automatic detection simply sets the ssd mount option, which 
again can be set manually, to either ssd or nossd, should you wish to do 
so.  The related ssd_spread and discard mount options are never set 
automatically, because they work better on some ssds than others and are 
thus left to admin option.

I'd recommend enabling the ssd mount option, and would recommend doing 
some research on your ssd, before deciding whether you want dup or single 
metadata.

In general, dup for metadata is more reliable without the high space cost 
dup for data would be, thus the reason it's enabled by default on 
spinning rust.  But some ssds have a firmware translation layer (FTL) 
with compression and deduplication features that would only write the one 
copy to physical media even if btrfs sent it two, in which case 
processing the second copy is simply a waste of cpu cycles and device-bus 
bandwidth.  Sandforce FTLs are known for this, marketing it as a 
feature.  OTOH, other ssds have FTLs that don't do this sort of 
transparent compression and dedup, storing exactly what they are sent, 
and they market /that/ as a feature.  The FTLs on my Corsair Neutrons (I 
forgot what the firmware brand is but google would know as that's where I 
found it when I did my research for this, note that they are _not_ 
Corsair Neutron GTXs, which I believe _may_ have the deduping FTLs) is 
the latter.

So if your ssd FTLs do dedup, single is the correct metadata choice and 
that's why it's the default.  Specifying dup metadata would end up having 
btrfs going thru the motions for nothing.  If they don't do dedup, then 
it's up to you whether you want the slightly increased performance and 
decreased space usage of single metadata due to not having to process 
that second copy, or would prefer the increased reliability of the second 
metadata copy that dup provides.

FWIW, I have btrfs directly on top of (partitioned) ssds, here, and it 
correctly detects them so I don't have to specify the ssd mount option.

As for mkfs.btrfs, most of my btrfs are pair-device raid1 for both data 
and metadata, but /boot is an exception, with a separate working /boot on 
one device and its backup on the other (because grub can point to only 
one /boot and I have the grub on each device pointed at its own /boot, so 
I can select the backup device to boot in BIOS, if an update messed up 
the working /boot or if I just refreshed the backup /boot and am testing 
it).  And I already said my FTLs don't do dedup, so I actually have a 
choice, and for both /boots, working copy and backup, I use dup mode.  
However, they're both very small, under a gig (256 MiB each), so I also 
use mixed-bg mode (mkfs.btrfs option --mixed), which means data and 
metadata are no longer separate but instead, stored on the same shared 
chunks, which means dup for metadata is also dup for data.  Which means 
/everything/ is duplicated, not just metadata, which in turn means those 
256 MiB btrfs are only 128 MiB capacity.  But it *does* mean both working 
and backup /boot still have two copies of both data and metadata, just as 
they would if I were using raid1 mode except both copies are on the same 
device.  Tho with the separate backup /boot on the other device, I still 
have the multi-device redundancy that way.  And that's exactly the way I 
want it. =:^)

(Tho in practice the 128 MiB capacity /boot is a bit smaller than I'd 
like, so next time I repartition, I'll probably make them 384 MiB each 
instead of 256 MiB, taking the space from my /var/log partition, which is 
512 MiB raid1 but never even half used unless I have a runaway logger 
event, so shrinking it to 384 MiB as well, to give the space to /boot and 
its backup, should be fine.)

-- 
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: ssd not detected on ssd drive

[covici]

Duncan <1i5t5.duncan@cox.net> wrote:

> covici posted on Thu, 24 Dec 2015 05:56:22 -0500 as excerpted:
> 
> > Hi.  I was making a few file systems on my ssd drives (using lvm on top)
> > and noticed that the ssd was not detected.  The only thing that happened
> > is that the metadata is duplicated.  Is this a problem, or a waste of
> > space?  If I wanted to remake the file systems -- which I don't want to
> > do unless necessary -- how would I prevent this?
> 
> SSD detection is based on the value of "rotational" for the device as 
> listed in sysfs.  Some virtual-block-device layers aren't transparent in 
> this regard and don't reflect the value of the lower levels upward to the 
> next.  It would seem lvm is one such non-transparent layer.
> 
> Of course you could manually set the rotational value in sysfs yourself, 
> or you could create a udev rule to do it for you, but there's really no 
> need, as all btrfs does with the value is automatically set some options 
> you can already specify directly, and specifying them directly at the 
> btrfs level is generally easier and more reliable anyway.
> 
> For mkfs.btrfs, the only thing ssd detection does is change the single-
> device-btrfs metadata default from its normal dup mode to single, and 
> since you can already specify which you want using the -m option, it's no 
> big deal.
> 
> At runtime, automatic detection simply sets the ssd mount option, which 
> again can be set manually, to either ssd or nossd, should you wish to do 
> so.  The related ssd_spread and discard mount options are never set 
> automatically, because they work better on some ssds than others and are 
> thus left to admin option.
> 
> I'd recommend enabling the ssd mount option, and would recommend doing 
> some research on your ssd, before deciding whether you want dup or single 
> metadata.
> 
> In general, dup for metadata is more reliable without the high space cost 
> dup for data would be, thus the reason it's enabled by default on 
> spinning rust.  But some ssds have a firmware translation layer (FTL) 
> with compression and deduplication features that would only write the one 
> copy to physical media even if btrfs sent it two, in which case 
> processing the second copy is simply a waste of cpu cycles and device-bus 
> bandwidth.  Sandforce FTLs are known for this, marketing it as a 
> feature.  OTOH, other ssds have FTLs that don't do this sort of 
> transparent compression and dedup, storing exactly what they are sent, 
> and they market /that/ as a feature.  The FTLs on my Corsair Neutrons (I 
> forgot what the firmware brand is but google would know as that's where I 
> found it when I did my research for this, note that they are _not_ 
> Corsair Neutron GTXs, which I believe _may_ have the deduping FTLs) is 
> the latter.
> 
> So if your ssd FTLs do dedup, single is the correct metadata choice and 
> that's why it's the default.  Specifying dup metadata would end up having 
> btrfs going thru the motions for nothing.  If they don't do dedup, then 
> it's up to you whether you want the slightly increased performance and 
> decreased space usage of single metadata due to not having to process 
> that second copy, or would prefer the increased reliability of the second 
> metadata copy that dup provides.
> 
> FWIW, I have btrfs directly on top of (partitioned) ssds, here, and it 
> correctly detects them so I don't have to specify the ssd mount option.
> 
> As for mkfs.btrfs, most of my btrfs are pair-device raid1 for both data 
> and metadata, but /boot is an exception, with a separate working /boot on 
> one device and its backup on the other (because grub can point to only 
> one /boot and I have the grub on each device pointed at its own /boot, so 
> I can select the backup device to boot in BIOS, if an update messed up 
> the working /boot or if I just refreshed the backup /boot and am testing 
> it).  And I already said my FTLs don't do dedup, so I actually have a 
> choice, and for both /boots, working copy and backup, I use dup mode.  
> However, they're both very small, under a gig (256 MiB each), so I also 
> use mixed-bg mode (mkfs.btrfs option --mixed), which means data and 
> metadata are no longer separate but instead, stored on the same shared 
> chunks, which means dup for metadata is also dup for data.  Which means 
> /everything/ is duplicated, not just metadata, which in turn means those 
> 256 MiB btrfs are only 128 MiB capacity.  But it *does* mean both working 
> and backup /boot still have two copies of both data and metadata, just as 
> they would if I were using raid1 mode except both copies are on the same 
> device.  Tho with the separate backup /boot on the other device, I still 
> have the multi-device redundancy that way.  And that's exactly the way I 
> want it. =:^)
> 
> (Tho in practice the 128 MiB capacity /boot is a bit smaller than I'd 
> like, so next time I repartition, I'll probably make them 384 MiB each 
> instead of 256 MiB, taking the space from my /var/log partition, which is 
> 512 MiB raid1 but never even half used unless I have a runaway logger 
> event, so shrinking it to 384 MiB as well, to give the space to /boot and 
> its backup, should be fine.)

Thanks for that interesting explanation -- in fact the ssd option is
automatically being detected, even though mkfs.btrfs did not detect ssd
properly.  I think I will leave things alone -- I am using Samsung 850
evo drives and will have to find out what they are doing, but its not
worth having to recreate the file system and copy all the files over
again!  Unless btrfstune or whatever can change the  feature on the fly.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com