Using BTRFS on SSD now ?
Hi,
I just received a new laptop with a Micron 256GB SSD, and I plan to install Fedora 20 onto it.
I'm considering either BTRFS or ext4 (over LUKS-encrypted LVM) for this machine, but I'm afraid BTRFS might generate too much writes and shorten the SSD lifespan... Or am I mistaken ?
Is there any pro/cons currently, on a 3.14 kernel, about using BTRFS along with an SSD ?
Is there specific advice about leaf size, use of compression, snapshots, (auto-)defrag etc, that might be relevant especially for SSDs ?
TIA.
Signature · 1 line
Swâmi Petaramesh <[email protected]> http://petaramesh.org PGP 9076E32E
Quoted 6 lines · On Thu, 5 Jun 2014 15:30:26 Swâmi Petaramesh wrote:
I just received a new laptop with a Micron 256GB SSD, and I plan to install Fedora 20 onto it.
I'm considering either BTRFS or ext4 (over LUKS-encrypted LVM) for this machine, but I'm afraid BTRFS might generate too much writes and shorten the SSD lifespan... Or am I mistaken ?
http://etbe.coker.com.au/2014/04/27/swap-breaking-ssd/
I recently did some calculations based on the usage of workstations I run on SSD storage. While the main focus of my post was swap and SSD I also did the calculations for the supposed life of SSDs and BTRFS filesystem use (all workstations in question run BTRFS). My conclusion is that if the most conservative (pessimistic) claims about SSD life are correct then there's still nothing to worry about.
Also I think that laptops tend to have less use than workstations, so unless your laptop is your main desktop system it should get less disk use than a typical workstation.
http://etbe.coker.com.au/2014/05/12/btrfs-vs-lvm/
I don't believe that LVM offers any benefit if you use BTRFS.
Quoted 2 lines
Is there any pro/cons currently, on a 3.14 kernel, about using BTRFS along with an SSD ?
Apart from BTRFS being new and still a bit buggy, not at all.
Quoted 2 lines
Is there specific advice about leaf size, use of compression, snapshots, (auto-)defrag etc, that might be relevant especially for SSDs ?
SSDs being a lot faster than spinning media remove many of these issues.
Signature · 2 lines
My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Thanks for the reply Russell :-)
Quoted 4 lines · Le vendredi 6 juin 2014 00:42:12 Russell Coker a écrit :
Also I think that laptops tend to have less use than workstations, so unless your laptop is your main desktop system it should get less disk use than a typical workstation.
My laptop (+ docking station) is going to be my daily main machine...
Quoted 1 line
I don't believe that LVM offers any benefit if you use BTRFS.
BTRFS cannot handle swap. A full disk encryption needs the swap to be encrypted as well. The only solution for getting both the swap and filesystems encrypted using the same key is to put both of them on an LVM itself luks- encrypted using dm-crypt.
All my machines have been made this way for *years*, so I know it works damn well ;-)
...And it also allows for hibernateing the system to (encrypted) swap space...
That's a pretty fine setup :-)
Signature · 1 line
Swâmi Petaramesh <[email protected]> http://petaramesh.org PGP 9076E32E
Quoted 4 lines · Swâmi Petaramesh
Quoted 2 lines
your laptop is your main desktop system it should get less disk use than a typical workstation.
My laptop (+ docking station) is going to be my daily main machine...
My laptop is my workstation, it's running almost 24/7 on SSD with btrfs. The main thing is having a good SSD (right now Samsung 840 EVO 1TB for me).
Quoted 6 lines
Quoted 1 line
I don't believe that LVM offers any benefit if you use BTRFS.
BTRFS cannot handle swap. A full disk encryption needs the swap to be encrypted as well. The only solution for getting both the swap and filesystems encrypted using the same key is to put both of them on an LVM itself luks- encrypted using dm-crypt.
Not at all.
Again, you really want to avoid the LVM layer. It will only make things slower.
This is my drive with encrypted swap
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1050623 524288 83 Linux /dev/sda2 1050624 42993663 20971520 83 Linux /dev/sda3 105908224 139462655 16777216 82 Linux swap / Solaris /dev/sda4 139462656 1953525167 907031256 83 Linux
See
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#btrfs_on_top_of_dmcrypt
and solutions like
https://github.com/gebi/keyctl_keyscript
Quoted 2 lines
All my machines have been made this way for *years*, so I know it works damn well ;-)
I've used LVM for years too, it makes things slower and less reliable.
Marc
Signature · 4 lines
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ Quoted 3 lines · Swâmi Petaramesh
Quoted 1 line
I don't believe that LVM offers any benefit if you use BTRFS.
BTRFS cannot handle swap.
Yes but Fedora's installer doesn't support swapfiles anyway. It only creates swap partitions (encrypted or not encrypted). And it does allow you to selectively only encrypt swap if you want.
Quoted 2 lines
A full disk encryption needs the swap to be
encrypted as well.
The Fedora installer will let you use regular partitions and encrypt them. LVM isn't necessary to achieve this.
Quoted 3 lines
The only solution for getting both the swap and filesystems encrypted using the same key is to put both of them on an LVM itself luks- encrypted using dm-crypt.
Why do they need to have the same key? The Fedora installer will let you do a Btrfs installation with swap as a separate partition, encrypt both partitions using one passphrase. Yes there are two LUKS device keys setup, but one passphrase unlocks both at the same time during boot.
Quoted 2 lines
All my machines have been made this way for *years*, so I know it works damn well ;-)
The Fedora installer won't even let you do this. Btrfs can't be put on LVM via anaconda.
Best practices for SSDs has been to encrypt each LV separately because dmcrypt was one thread per logical device. For an SSD this can make a big difference because it's possible to pin that single encryption thread and turn it into a bottle neck. There are multithreaded dmcrypt patches but I have no idea if it's in mainline kernels and if it gets used by default.
Quoted 2 lines
…And it also allows for hibernateing the system to (encrypted) swap space...
*shrug* that's hardware specific, whether it works or not. Right now hibernation in general, let alone encrypted, sucks on Linux right now. It and suspend are totally busted on all of my hardware right now, and forums are littered with people not able to get it to work, or having to become virtual experts getting it to work.
Chris Murphy
Quoted 8 lines · Swâmi Petaramesh
Hi,
I just received a new laptop with a Micron 256GB SSD, and I plan to install Fedora 20 onto it.
I'm considering either BTRFS or ext4 (over LUKS-encrypted LVM) for this machine, but I'm afraid BTRFS might generate too much writes and shorten the SSD lifespan... Or am I mistaken ?
Yeah,
1) a lot of us use btrfs on SSDs
2) SSD write lifetime is more than you think
However SSDs, especially at least earlier models of the one you got, still randomly die, and take your data with them. It's not because of number of writes, but bad firmware and/or a single chip that dies and isn't redundant on some drives.
Quoted 2 lines
Is there any pro/cons currently, on a 3.14 kernel, about using BTRFS along with an SSD ?
It's not foolproof, but works well enough for many. Have backups, but because of your SSD, you should definitely have backups anyway.
Quoted 2 lines
Is there specific advice about leaf size, use of compression, snapshots, (auto-)defrag etc, that might be relevant especially for SSDs ?
compression: lzo, not zlib (zlib will slow down your SSD) snapshots:
http://marc.merlins.org/perso/btrfs/2014-03.html#Btrfs-Tips_-How-To-Setup-Netapp-Style-Snapshots
auto-defrag: not really (read the archives) other options: leave default
add -o discard to mount options
Do not use LVM, it's totally unnecessary and will slow you down. Dmcrypt is ok, however add discard to cryptsetup options too:
root2 /dev/sda2 /pwd luks,discard
legolas:~# grep discard /proc/cmdline root=/dev/mapper/cryptroot ro rootflags=subvol=root cryptopts=source=/dev/sda4,keyscript=/sbin/cryptgetpw,discard
Marc
Signature · 4 lines
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ Quoted 2 lines · On Thu, 5 Jun 2014 07:56:32 -0700 Marc MERLIN <[email protected]> wrote:
However SSDs, especially at least earlier models of the one you got, still randomly die, and take your data with them.
Yeah, a PSA of sorts: take whatever SSDs you have and use, and go to the manufacturer's website (right *NOW* :) to check if they have a newer firmware, or to ensure that you have the latest version. There are such horrible bugs being found and fixed in those, that upgrading the firmware is absolutely *not* the case of "if it's not broken, don't fix it". Also your SSD may gain niceties such as a working TRIM support (that was sometimes disabled/broken in earlier releases).
Signature · 2 lines
With respect, Roman
Quoted 3 lines · Roman Mamedov
Yeah, a PSA of sorts: take whatever SSDs you have and use, and go to the manufacturer's website (right *NOW* :) to check if they have a newer firmware, or to ensure that you have the latest version. There are such horrible
bugs
Quoted 5 lines
being found and fixed in those, that upgrading the firmware is absolutely *not* the case of "if it's not broken, don't fix it". Also your SSD may gain niceties such as a working TRIM support (that was sometimes disabled/broken in earlier releases).
Sometimes the latest firmware has isuues which were not present earlier (like in my case with Crucial M4) so we have to be careful and listen to other users, Maybe M4 is ok now, I'll have to check again,
Quoted 2 lines · Marc MERLIN
Dmcrypt is
ok, however add discard to cryptsetup options too
Be aware, that discard used with dm-crypt may have security implications.
Cheers,
Chris.
Quoted 2 lines · Le jeudi 5 juin 2014 17:59:48 Christoph Anton Mitterer a écrit :
Be aware, that discard used with dm-crypt may have security implications.
Thanks, I knew :-)
Signature · 5 lines
Swâmi Petaramesh <[email protected]> http://petaramesh.org PGP 9076E32E Le sage n’est pas celui qui discrimine, c’est celui qui réunit les lambeaux de lumière, d’où qu’ils proviennent. -- Umberto Eco
Quoted 2 lines · Marc MERLIN
compression: lzo, not zlib (zlib will slow down your SSD)
I've had mixed results, where benchmarking suggests lzo is faster, but then zlib actually feels faster. For sure forced zlib compression can be dreadful, but I kinda expect that and therefore don't use it. These days I'm not using any compression. I think a lot of the benchmarks suggesting one way or the other are just the wrong benchmarks to look at for this sort of thing, as they aren't testing the actual workloads that are typical.
Quoted 3 lines
snapshots:
http://marc.merlins.org/perso/btrfs/2014-03.html#Btrfs-Tips_-How-To-Setup-Netapp-Style-Snapshots
auto-defrag: not really (read the archives)
Definitely there are some issues, it's probably why its not yet default. So I'd either not use it, or use it with the point of testing it to make it better.
Quoted 2 lines
other options: leave default
add -o discard to mount options
I disagree. The older the SSD almost certainly the worse its TRIM behavior will be, resulting in hangs possibly long hangs. There's a whole bunch of stuff written on lkml about non-queued TRIM ugliness. I think most users are better off issuing fstrim once a week until queued TRIM devices are in the wild and well tested.
The one case were file system discard is useful is not so much to inform the physical device but the next lower layer logical block device like md raid or LVM thinp so that the right unused blocks are freed up.
Quoted 4 lines
Do not use LVM, it's totally unnecessary and will slow you down. Dmcrypt is ok, however add discard to cryptsetup options too:
root2/dev/sda2/pwd luks,discard
So again in this case I'd say don't use discard. Or at the very least, test it first. My SSD is reportedly not so bad in this regard, but I find even 2-3 second hang of *all* read/write events when deleting a bunch of files to be abhorrent. Some people report much, much longer delays as the SSD then also does immediate and aggressive GC.
I'd say, what slight additional wear occurs from not using discard, makes the SSD die sooner in order to justify getting a new SSD that maybe (?) doesn't have this problem anymore.
Chris Murphy
Quoted 1 line · Chris Murphy
I'd say, what slight additional wear occurs from not using discard, makes the SSD die sooner in order to justify getting a new SSD that maybe (?) doesn't have this problem anymore.
Your points are well noted, although on the flipside I've had an SSD perform horribly because without TRIM, it had to use its own garbage collection which was horrible. Also, if you rely on garbage collection, you need to make sure to make an empty partition with 5 or 10% of your space and never use it so that yoru SSD can easily use that for garbage collection without impacting performance too much.
Marc
Signature · 4 lines
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ Marc MERLIN posted on Thu, 05 Jun 2014 12:05:26 -0700 as excerpted:
Quoted 11 lines · Chris Murphy
Quoted 3 lines
I'd say, what slight additional wear occurs from not using discard, makes the SSD die sooner in order to justify getting a new SSD that maybe (?) doesn't have this problem anymore.
Your points are well noted, although on the flipside I've had an SSD perform horribly because without TRIM, it had to use its own garbage collection which was horrible. Also, if you rely on garbage collection, you need to make sure to make an empty partition with 5 or 10% of your space and never use it so that yoru SSD can easily use that for garbage collection without impacting performance too much.
This subthread nicely addresses the subject next on my list to tackle in relation to this thread. =:^)
Here's the deal with trim/discard (two different names for the same feature):
Early SSDs didn't have it or had proprietary implementations, quickly making the community aware of the need. Any decent and reasonably current SSD should offer the now standardized feature, but unfortunately, the initial standard made the trim instruction non-queued, so on a lot of hardware, issuing a trim instruction acts as an IO barrier, disrupting continued traffic to/from the device until the existing queue is emptied and the trim instruction completed, after which the queue can refill... until the next such operation.
As a result, while most current hardware supports trim/discard, on a lot of it, trim/discard in normal operation can reduce performance substantially. =:^(
For this sort of hardware, trim works best when used in flag-day fashion, at mkfs.btrfs for instance (and it /does/ issue a whole-range trim before setting up the filesystem), and periodically using tools such as fstrim. It does /not/ work so well when used routinely as part of the normal IO flow, when deleting a file or COWing a block, for instance, because these disrupt the normal hardware operations queue.
OTOH, certain high-performance hardware goes beyond the current standard and does a queued trim, without forcing a flush of the queue in the process. But this hardware tends to be rather rare and expensive, and general claims to support trim can't be taken to indicate support for this sort of trim at all, so it tends to be a rather poor basis for a general recommendation or a routine-trim-by-default choice.
Then there's the encrypted device implications, which tend to favor not enabling discard/trim by default as well, due to the information leakage potential.
Thus we have the current situation, discard (aka trim) as a SEPARATE mount option from ssd, with ssd enabled by default where non-rotational storage is detected, but discard always requiring explicit invocation, as it simply isn't appropriate for a default option, at this point.
FWIW, the latest SATA standard (SATA 3.something) is said to explicitly support or perhaps even require queued trim support. However, actual hardware with this support remains rare, at this point.
(FWIW, in new enough versions of smartctl, smartctl -i will have a "SATA Version is:" line, but even my newer Corsair Neutrons report only SATA 2.5, so obviously they don't support queued trim by the standard, tho it's still possible they implement it beyond the standard, I simply don't know.)
Meanwhile, most authorities recommend leaving some portion of an SSD, typically 20-30% unformatted, thus giving the firmware plenty of room to manage erase-blocks as necessary, and that normally lessens the requirement to keep a nicely trimmed filesystem as well.
Here, it happened that when I was looking for SSDs, the 128 GB or so I figured I needed were either out of stock or the 256 GB or so versions were only a few dollars more expensive, so I ended up buying 256 GB versions where I had intended to buy 128 GB versions. So in addition to actually putting more on the SSDs than I had originally intended (I still use lower cost spinning rust for my media partition, tho), I'm actually running only a bit over 50% partitioned, as well, with the rest of the SSDs being entirely unused, reserved for firmware erase-block management or for future use. So I haven't actually worried much about whether I could efficiently turn on trim/discard or not, I just let the over- provisioning handle it, along with doing a fresh mkfs.btrfs and restore from backup every few kernel cycles (and thus getting the mkfs.btrfs whole-filesystem trim in the process), in ordered to take advantage of the latest btrfs filesystem features. =:^) I do occasional fstrims as well, but haven't worried about doing that in any scheduled fashion either, simply because what with fresh mkfs.btrfs every few kernel cycles and with nearly 100% overprovisioning, I've not needed to. Tho I probably will once btrfs development slows down and there aren't new filesystem format features to be taken advantage of every few kernel cycles.
Signature · 3 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Duncan" == Duncan <[email protected]> writes:
Duncan> OTOH, certain high-performance hardware goes beyond the current Duncan> standard and does a queued trim, without forcing a flush of the Duncan> queue in the process. But this hardware tends to be rather rare Duncan> and expensive,
Queued trim has started to appear in consumer SSDs. However, since we're the only OS that supports it the feature has come off to a bumpy start. We tried to enable it on a drive model that passed testing here but we had to revert to unqueued when bug reports started rolling in this week.
Duncan> (FWIW, in new enough versions of smartctl, smartctl -i will have Duncan> a "SATA Version is:" line, but even my newer Corsair Neutrons Duncan> report only SATA 2.5, so obviously they don't support queued Duncan> trim by the standard, tho it's still possible they implement it Duncan> beyond the standard, I simply don't know.)
The reported SATA version is in no way indicative of whether a drive supports queued trim. The capability flag was put a highly unusual place in the protocol. I posted a patch that makes this information available in sysfs a while back. However, the patch is currently being reworked to support a debug override...
Until then, the following command will give you the answer:
# smartctl -l gplog,0x13 /dev/sda | grep 0000:
0000000: 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 |................|
^^ ^^
These two 01 fields indicate that the drive supports queued trim.Signature · 1 line
Martin K. Petersen Oracle Linux Engineering
Quoted 5 lines · Martin K. Petersen
Queued trim has started to appear in consumer SSDs. However, since we're the only OS that supports it the feature has come off to a bumpy start. We tried to enable it on a drive model that passed testing here but we had to revert to unqueued when bug reports started rolling in this week.
There's a RHBZ I ran across ~6 months ago with a purportedly SATA rev 3.1 SSD, (m?)SATA, and queued trim caused some big enough of a problem that the model is black listed for queued trim. I don't remember if it was massive fs corruption or if it bricked the drive or what. So yeah they're rare enough that it's like, OK we're sorta starting over from scratch.
Chris Murphy
Martin K. Petersen posted on Thu, 05 Jun 2014 19:58:26 -0400 as excerpted:
Quoted 11 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Duncan" == Duncan <[email protected]> writes:
Duncan> OTOH, certain high-performance hardware goes beyond the current Duncan> standard and does a queued trim, without forcing a flush of the Duncan> queue in the process. But this hardware tends to be rather rare Duncan> and expensive,
Queued trim has started to appear in consumer SSDs. However, since we're the only OS that supports it the feature has come off to a bumpy start. We tried to enable it on a drive model that passed testing here but we had to revert to unqueued when bug reports started rolling in this week.
[more elided]
Thanks. Fresher and better information than I had. =:^)
Signature · 3 lines
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
Quoted 4 lines · Martin K. Petersen
Until then, the following command will give you the answer:
# smartctl -l gplog,0x13 /dev/sda | grep 0000: 0000000: 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
|................| > ^^ ^^
Quoted 2 lines
These two 01 fields indicate that the drive supports queued trim.
Is mine a dinosaur drive?
# smartctl -l gplog,0x13 /dev/sda smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.14.5-gentoo-r1melf] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
General Purpose Log 0x13 does not exist (override with '-T permissive' option)
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Pavel" == Pavel Volkov <[email protected]> writes:
Pavel> Is mine a dinosaur drive?
[...]
Pavel> General Purpose Log 0x13 does not exist (override with '-T Pavel> permissive' option)
The only flags defined in general purpose log page 0x13 are the queued trim ones. So there is no compelling reason for a drive vendor to implement that page unless the drive actually supports queued trim. And consequently it's perfectly normal for that page to be absent.
Signature · 1 line
Martin K. Petersen Oracle Linux Engineering
Chris Murphy posted on Thu, 05 Jun 2014 12:13:37 -0600 as excerpted:
Quoted 5 lines
Quoted 1 line
auto-defrag: not really (read the archives)
Definitely there are some issues, it's probably why its not yet default. So I'd either not use it, or use it with the point of testing it to make it better.
Usage-pattern is the big one with autodefrag. I'm personally an autodefrag user and booster, but my use-case has few if any of the big red-flag file-access-pattern cases, and several where there's reasonable benefit.
Autodefrag's target: Small (up to a few hundred MiB, safely under a gig and preferably under half a gig) internal-rewrite-pattern files typically found on desktop/laptop purpose systems. Typical example: Firefox and thunderbird sqlite database files. Also: Multi-file simultaneous write, since this write pattern can trigger fragmentation as well, that autodefrag's background rewrite strategy should counter/fix.
Autodefrag sees writes that update these files and on copy-on-write (COW) filesystems such as btrfs trigger fragmentation, and queues the affected files for background sequential rewrite and defrag. On this type of file this strategy works very well, neutralizing the fragmentation that would otherwise plague these files on btrfs, without huge ware or performance issues.
Autodefrag's bane: Large (gig-plus) internal-rewrite-pattern files, traditionally less often found on desktop/laptop systems altho they are becoming more common. Typical examples: VM-images and database files over a gig in size.
It can be noted that these types of files are a challenge for any COW- based filesystem, btrfs being no exception. Like me, you may have few to none of these, but if you do, I strongly recommend reading up on the NOCOW file attribute and related strategies, as it's very likely the single most common performance issue seen with btrfs, autodefrag or not and ssd or not. See the "Very slow filesystem" thread posted by Igor M (igork20 at gmail) yesterday.
Autodefrag neutral: Sequentially-written files in general and append-only files such as the typical logfile, particularly when only one file is being written at once.
Autodefrag strategy hint: If you choose to use this mount option, it's best to use it from THE FIRST TIME file data is written to the filesystem. Unfortunately, as of a year or so ago at least, various distro installers did NOT use this flag by default when installing on btrfs, resulting in a lot of out-of-the-box installation fragmentation on btrfs. Turning it on only after installation thus resulted in a performance drag for several days, until autodefrag caught up with the backlog. So if installing to btrfs, verify that this flag is turned on by the installer for the install itself, if necessary using the custom option at this step to turn it on at initial mount, before all those files are copied over by the installer.
As an installation-time-autodefrag alternative, run btrfs filesystem defrag -r (recursive) on the filesystem after installation, before you start using it much and definitely before the first btrfs snapshot (or delete that snapshot first, do the defrag, then create a new snapshot). That will take care of all the fragmentation at once, and by doing it without snapshots taken, you avoid data duplication due to defrag being temporarily snapshot-aware disabled, until they fix the scaling issues that snapshot-awareness was triggering.
Unless you have autodefrag-bane files to worry about (and if you do, I strongly recommend that you do your research on that and special-case them with NOCOW and etc), even on ssd, autodefrag should be a small bonus due to saved IOPS, tho not to the extent it would be on spinning rust due to ssd's zero-seek-time.
Signature · 3 lines
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
Am Donnerstag, 5. Juni 2014, 15:30:26 schrieb Swâmi Petaramesh:
Quoted 8 lines
Hi,
I just received a new laptop with a Micron 256GB SSD, and I plan to install Fedora 20 onto it.
I'm considering either BTRFS or ext4 (over LUKS-encrypted LVM) for this machine, but I'm afraid BTRFS might generate too much writes and shorten the SSD lifespan... Or am I mistaken ?
Relax.
I don´t know why you come to the conclusion BTRFS would create more writes than other filesystems, but here are facts:
BTRFS on Intel SSD 320, since about month or so as RAID 1 on Intel SSD 320 and Crucial m5 mSATA. BTRFS on Intel SSD 320 since I think a bit more than three years for now.
SMART Attributes Data Structure revision number: 5 Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 3 Spin_Up_Time 0x0020 100 100 000 Old_age Offline - 0 4 Start_Stop_Count 0x0030 100 100 000 Old_age Offline - 0 5 Reallocated_Sector_Ct 0x0032 100 100 000 Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 10289 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 2797 170 Reserve_Block_Count 0x0033 100 100 010 Pre-fail Always - 0 171 Program_Fail_Count 0x0032 100 100 000 Old_age Always - 0 172 Erase_Fail_Count 0x0032 100 100 000 Old_age Always - 169 183 Runtime_Bad_Block 0x0030 100 100 000 Old_age Offline - 1 184 End-to-End_Error 0x0032 100 100 090 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 192 Unsafe_Shutdown_Count 0x0032 100 100 000 Old_age Always - 241 199 UDMA_CRC_Error_Count 0x0030 100 100 000 Old_age Offline - 0 225 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 449085 226 Workld_Media_Wear_Indic 0x0032 100 100 000 Old_age Always - 2204365 227 Workld_Host_Reads_Perc 0x0032 100 100 000 Old_age Always - 49 228 Workload_Minutes 0x0032 100 100 000 Old_age Always - 13212562 232 Available_Reservd_Space 0x0033 100 100 010 Pre-fail Always - 0 233 Media_Wearout_Indicator 0x0032 099 099 000 Old_age Always - 0 241 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 449085 242 Host_Reads_32MiB 0x0032 100 100 000 Old_age Always - 1144183
Media Wearout Indicator was 100 initially, now is 99. Thus the SSDs considers itself to be basically new. Use search machine to find PDF of Intel about that value.
And 449085 32 MiB Host Writes with KDE session, desktop search Nepomuk, now Baloo, Akonadi setups with insanely sized mailbox and what not. Thats:
irb(main):027:0> 449085 * 32 / 1024.0 / 1024.0
=> 13.704986572265625
13,7 TiB. This Intel SSD is specced for a useful life of 5 years with 20 GB host writes *each day*. Thats about 7 TiB per year, even if you use 1000 as base here. 3 years * 7 TiB = 21 TiB.
So look at your SSD endurance specification and then just relax :)
Ciao,
Signature · 2 lines
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Quoted 8 lines · Swâmi Petaramesh
Hi,
I just received a new laptop with a Micron 256GB SSD, and I plan to install Fedora 20 onto it.
I'm considering either BTRFS or ext4 (over LUKS-encrypted LVM) for this machine, but I'm afraid BTRFS might generate too much writes and shorten the SSD lifespan... Or am I mistaken ?
Is it certain Btrfs single profile writes more metadata than other file systems? Since the journal is the file system, I'd expect the same or less writes with Btrfs than other file systems which repetitively write a separate journal. In any case it's a really minor consideration. SSD wear is to the point you'd have to practically be abusing the drive (enterprise demand workloads on a consumer SSD).
Btrfs does work over dm layers including on LVM and dmcrypt and both. There have been some problems recently reported on the list that involve LVM and dmcrypt but I have no idea if those are contributing or merely complicating factors. Unless you have a really specific requirement offered by LVM, or you're just looking to test with intent to break to help make the combination better for everyone, I'd advise against using it. Btrfs on dmcrypt should definitely work (I've done it for a few years and haven't had issues). There's some advantage of LVM thinp LVs, I'm not sure if Btrfs is going to offer its own thin provisioning, if not then Btrfs on LVM thinp needs to work to but I've only done a little bit of testing with this. It works, but with obscenely sized virtual LVs with totally insufficient backing, I've had some problems, ergo if you want to go this route you basically are signing up for detailed and concise problem reporting.
Quoted 2 lines
Is there any pro/cons currently, on a 3.14 kernel, about using BTRFS along with an SSD ?
If anything, more even wear on older devices that don't do their own wear leveling.
Quoted 2 lines
Is there specific advice about leaf size, use of compression, snapshots, (auto-)defrag etc, that might be relevant especially for SSDs ?
Defaults are fine. Longer term discard and autodefrag mount options will have some clearer benefits.
I pretty much gave up on discard with a Samsung 830 SSD. In both Linux and OS X I'd get these short hangs, maybe just a couple seconds or so. They were more annoying on OS X than on Linux.
Fragmentation is probably not a big performance problem on SSDs. At least on my hardware I haven't noticed a difference with even highly fragmented VM images that I haven't set xattr +C (nodatacow) on. Neverthless I've done some testing of both +C on /var/log/journal since systemd journals quickly get very fragmented on Btrfs as do VM images. I'm pretty sure all the bugs I reported about that were long ago fixed, I haven't had any recurrences. So now I'm not using +C but rather autodefrag for the past 8 months. A few months ago I had some systemd journal corruptions but I can't point the finger at either Btrfs or autodefrag because the corruptions coincided with unclean shutdowns. And it even could be an issue with systemd-journald. If I manage to reproduce the corruption, then I'll have to see about also reproducing it on either ext4 or xfs.
Compression I no longer use. I'd probably not use forced compression on an SSD because it'll probably just slow things down.
Snapshots haven't been a problem, I'm even doing my own atomic yum/dnf updates by creating rw snapshots, chrooting them, and then running the update in the chroot. So the snapshots are what get the system update, if it fails I can just blow away the snapshots, and if it succeeds I haven't changed anything on the running OS mounted system, I can point grub to the new subvolume to boot from and reboot to the updated system whenever I want.
For what it's worth, Fedora 20's installer doesn't let you have a /boot on Btrfs. It must be on ext4. So if you want /boot on Btrfs you get to do this post-install. The current bug there being worked on (patches upstream) is kernel updates depend on grubby adding the proper entry in grub.cfg which fails with /boot is on Btrfs. As a work around to the grubby message you get when doing kernel updates, you can just run grub2-mkconfig -o <grub.cfg location> to create a new correct grub.cfg. I'm expecting this to all "just work" in Fedora 21.
Chris Murphy