From: "Swâmi Petaramesh" <swami@petaramesh.org>
To: Austin S Hemmelgarn <ahferroin7@gmail.com>
Cc: Linux BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: BTRFS, SSD and single metadata
Date: Mon, 16 Jun 2014 13:18:24 +0200 [thread overview]
Message-ID: <4823159.jCObc9Zrv0@vajra> (raw)
In-Reply-To: <539ED083.5050705@gmail.com>
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.
--
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E
next prev parent reply other threads:[~2014-06-16 11:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 7:54 BTRFS, SSD and single metadata Swâmi Petaramesh
2014-06-16 11:09 ` Austin S Hemmelgarn
2014-06-16 11:18 ` Swâmi Petaramesh [this message]
2014-06-16 11:23 ` Austin S Hemmelgarn
2014-06-16 12:01 ` Russell Coker
2014-06-16 12:16 ` Duncan
2014-06-16 12:26 ` Swâmi Petaramesh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4823159.jCObc9Zrv0@vajra \
--to=swami@petaramesh.org \
--cc=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox