On Sat, Nov 7, 2015 at 4:05 PM, Christoph Anton Mitterer <cales...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
