Re: Btrfs/SSD

Am Tue, 16 May 2017 14:21:20 +0200 schrieb Tomasz Torcz : > On Tue, May 16, 2017 at 03:58:41AM +0200, Kai Krakow wrote: > > Am Mon, 15 May 2017 22:05:05 +0200 > > schrieb Tomasz Torcz : > > > [...] > > > > > > Let me add my 2 cents.

Re: Btrfs/SSD

On 2017-05-16 08:21, Tomasz Torcz wrote: On Tue, May 16, 2017 at 03:58:41AM +0200, Kai Krakow wrote: Am Mon, 15 May 2017 22:05:05 +0200 schrieb Tomasz Torcz : My drive has # smartctl -a /dev/sda | grep LBA 241 Total_LBAs_Written 0x0032 099 099 000Old_age

Re: Btrfs/SSD

On Tue, May 16, 2017 at 03:58:41AM +0200, Kai Krakow wrote: > Am Mon, 15 May 2017 22:05:05 +0200 > schrieb Tomasz Torcz : > > > > Yes, I considered that, too. And when I tried, there was almost no > > > perceivable performance difference between bcache-writearound and > > >

Re: Btrfs/SSD

On 2017-05-15 15:49, Kai Krakow wrote: Am Mon, 15 May 2017 08:03:48 -0400 schrieb "Austin S. Hemmelgarn" : That's why I don't trust any of my data to them. But I still want the benefit of their speed. So I use SSDs mostly as frontend caches to HDDs. This gives me big

Re: Btrfs/SSD

Kai Krakow posted on Mon, 15 May 2017 21:12:06 +0200 as excerpted: > Am Mon, 15 May 2017 14:09:20 +0100 > schrieb Tomasz Kusmierz : >> >> Not true. When HDD uses 10% (10% is just for easy example) of space >> as spare than aligment on disk is (US - used sector, SS - spare

Re: Btrfs/SSD

Am Mon, 15 May 2017 22:05:05 +0200 schrieb Tomasz Torcz : > On Mon, May 15, 2017 at 09:49:38PM +0200, Kai Krakow wrote: > > > > > It's worth noting also that on average, COW filesystems like BTRFS > > > (or log-structured-filesystems will not benefit as much as > > >

Re: Btrfs/SSD

On Mon, May 15, 2017 at 09:49:38PM +0200, Kai Krakow wrote: > > > It's worth noting also that on average, COW filesystems like BTRFS > > (or log-structured-filesystems will not benefit as much as > > traditional filesystems from SSD caching unless the caching is built > > into the filesystem

Re: Btrfs/SSD

Am Mon, 15 May 2017 08:03:48 -0400 schrieb "Austin S. Hemmelgarn" : > > That's why I don't trust any of my data to them. But I still want > > the benefit of their speed. So I use SSDs mostly as frontend caches > > to HDDs. This gives me big storage with fast access. Indeed,

Re: Btrfs/SSD

Am Mon, 15 May 2017 07:46:01 -0400 schrieb "Austin S. Hemmelgarn" : > On 2017-05-12 14:27, Kai Krakow wrote: > > Am Tue, 18 Apr 2017 15:02:42 +0200 > > schrieb Imran Geriskovan : > > > >> On 4/17/17, Austin S. Hemmelgarn

Re: Btrfs/SSD

Am Mon, 15 May 2017 14:09:20 +0100 schrieb Tomasz Kusmierz : > > Traditional hard drives usually do this too these days (they've > > been under-provisioned since before SSD's existed), which is part > > of why older disks tend to be noisier and slower (the reserved > >

Re: Btrfs/SSD

> Traditional hard drives usually do this too these days (they've been > under-provisioned since before SSD's existed), which is part of why older > disks tend to be noisier and slower (the reserved space is usually at the far > inside or outside of the platter, so using sectors from there to

Re: Btrfs/SSD

On 2017-05-12 14:36, Kai Krakow wrote: Am Fri, 12 May 2017 15:02:20 +0200 schrieb Imran Geriskovan : On 5/12/17, Duncan <1i5t5.dun...@cox.net> wrote: FWIW, I'm in the market for SSDs ATM, and remembered this from a couple weeks ago so went back to find it. Thanks.

Re: Btrfs/SSD

On 2017-05-12 14:27, Kai Krakow wrote: Am Tue, 18 Apr 2017 15:02:42 +0200 schrieb Imran Geriskovan : On 4/17/17, Austin S. Hemmelgarn wrote: Regarding BTRFS specifically: * Given my recently newfound understanding of what the 'ssd' mount

Re: Btrfs/SSD

On 5/15/17, Tomasz Kusmierz wrote: > Theoretically all sectors in over provision are erased - practically they > are either erased or waiting to be erased or broken. > Over provisioned area does have more uses than that. For example if you have > a 1TB drive where you

Re: Btrfs/SSD

Theoretically all sectors in over provision are erased - practically they are either erased or waiting to be erased or broken. What you have to understand is that sectors on SSD are not where you really think they are - they can swap place with sectors with over provisioning are, they can swap

Re: Btrfs/SSD

Theoretically all sectors in over provision are erased - practically they are either erased or waiting to be erased or broken. What you have to understand is that sectors on SSD are not where you really think they are - they can swap place with sectors with over provisioning are, they can swap

Re: Btrfs/SSD

On 5/14/17, Tomasz Kusmierz wrote: > In terms of over provisioning of SSD it’s a give and take relationship … on > good drive there is enough over provisioning to allow a normal operation on > systems without TRIM … now if you would use a 1TB drive daily without TRIM > and

Re: Btrfs/SSD (my -o ssd "summary")

sk space that is actually free ….. > > So, to summaries: > - don’t try to outsmart built in mechanics of SSD (people that > suggest that are just morons that want to have 5 minutes of fame). This is exactly what the btrfs ssd options are trying to do. Still, I don't think it's

Re: Btrfs/SSD

All stuff that Chris wrote holds true, I just wanted to add flash specific information (from my experience of writing low level code for operating flash) So with flash, to erase you have to erase a large allocation block, usually it used to be 128kB (plus some crc data and stuff makes more than

Re: Btrfs/SSD

On Sat, May 13, 2017 at 3:39 AM, Duncan <1i5t5.dun...@cox.net> wrote: > When I was doing my ssd research the first time around, the going > recommendation was to keep 20-33% of the total space on the ssd entirely > unallocated, allowing it to use that space as an FTL erase-block > management

Re: Btrfs/SSD

Imran Geriskovan posted on Fri, 12 May 2017 15:02:20 +0200 as excerpted: > On 5/12/17, Duncan <1i5t5.dun...@cox.net> wrote: >> FWIW, I'm in the market for SSDs ATM, and remembered this from a couple >> weeks ago so went back to find it. Thanks. =:^) >> >> (I'm currently still on quarter-TB

[OT] SSD performance patterns (was: Btrfs/SSD)

Am Sat, 13 May 2017 09:39:39 + (UTC) schrieb Duncan <1i5t5.dun...@cox.net>: > Kai Krakow posted on Fri, 12 May 2017 20:27:56 +0200 as excerpted: > > > In the end, the more continuous blocks of free space there are, the > > better the chance for proper wear leveling. > > Talking about

Re: Btrfs/SSD

> Anyway, that 20-33% left entirely unallocated/unpartitioned > recommendation still holds, right? I never liked that idea. And I really disliked how people considered it to be (and even passed it down as) some magical, absolute stupid-proof fail-safe thing (because it's not). 1: Unless you

Re: Btrfs/SSD

Am Sat, 13 May 2017 14:52:47 +0500 schrieb Roman Mamedov : > On Fri, 12 May 2017 20:36:44 +0200 > Kai Krakow wrote: > > > My concern is with fail scenarios of some SSDs which die unexpected > > and horribly. I found some reports of older Samsung SSDs

Re: Btrfs/SSD

On Fri, 12 May 2017 20:36:44 +0200 Kai Krakow wrote: > My concern is with fail scenarios of some SSDs which die unexpected and > horribly. I found some reports of older Samsung SSDs which failed > suddenly and unexpected, and in a way that the drive completely died: > No

Re: Btrfs/SSD

Kai Krakow posted on Fri, 12 May 2017 20:27:56 +0200 as excerpted: > In the end, the more continuous blocks of free space there are, the > better the chance for proper wear leveling. Talking about which... When I was doing my ssd research the first time around, the going recommendation was to

Re: Btrfs/SSD

On 5/12/17, Kai Krakow wrote: > I don't think it is important for the file system to know where the SSD > FTL located a data block. It's just important to keep everything nicely > aligned with erase block sizes, reduce rewrite patterns, and free up > complete erase blocks as

Re: Btrfs/SSD

Am Fri, 12 May 2017 15:02:20 +0200 schrieb Imran Geriskovan : > On 5/12/17, Duncan <1i5t5.dun...@cox.net> wrote: > > FWIW, I'm in the market for SSDs ATM, and remembered this from a > > couple weeks ago so went back to find it. Thanks. =:^) > > > > (I'm currently

Re: Btrfs/SSD

Am Tue, 18 Apr 2017 15:02:42 +0200 schrieb Imran Geriskovan : > On 4/17/17, Austin S. Hemmelgarn wrote: > > Regarding BTRFS specifically: > > * Given my recently newfound understanding of what the 'ssd' mount > > option actually does, I'm

Re: Btrfs/SSD

On 5/12/17, Duncan <1i5t5.dun...@cox.net> wrote: > FWIW, I'm in the market for SSDs ATM, and remembered this from a couple > weeks ago so went back to find it. Thanks. =:^) > > (I'm currently still on quarter-TB generation ssds, plus spinning rust > for the larger media partition and backups, and

Re: Btrfs/SSD

Austin S. Hemmelgarn posted on Mon, 17 Apr 2017 07:53:04 -0400 as excerpted: > * In my personal experience, Intel, Samsung, and Crucial appear to be > the best name brands (in relative order of quality). I have personally > had bad experiences with SanDisk and Kingston SSD's, but I don't have >

Re: Btrfs/SSD

On Mon, Apr 17, 2017 at 4:55 PM, Hans van Kranenburg <hans.van.kranenb...@mendix.com> wrote: > On 04/17/2017 09:22 PM, Imran Geriskovan wrote: >> [...] >> >> Going over the thread following questions come to my mind: >> >> - What exactly does btrfs

Re: Btrfs/SSD

On 2017-04-18 09:02, Imran Geriskovan wrote: On 4/17/17, Austin S. Hemmelgarn wrote: Regarding BTRFS specifically: * Given my recently newfound understanding of what the 'ssd' mount option actually does, I'm inclined to recommend that people who are using high-end SSD's

Re: Btrfs/SSD

nt or not needed) just to save the SSD lifetime. Going over the thread following questions come to my mind: - What exactly does btrfs ssd option does relative to plain mode? Assuming I understand what it does correctly, it prioritizes writing into larger, 2MB aligned chunks of free-space, wh

Re: Btrfs/SSD

On Tue, Apr 18, 2017 at 07:31:34AM -0400, Austin S. Hemmelgarn wrote: > On 2017-04-17 15:39, Chris Murphy wrote: > >On Mon, Apr 17, 2017 at 1:26 PM, Austin S. Hemmelgarn > > wrote: > >>On 2017-04-17 14:34, Chris Murphy wrote: [...] > >It's almost like we need these things

Re: Btrfs/SSD

On 2017-04-17 15:39, Chris Murphy wrote: On Mon, Apr 17, 2017 at 1:26 PM, Austin S. Hemmelgarn wrote: On 2017-04-17 14:34, Chris Murphy wrote: Nope. The first paragraph applies to NVMe machine with ssd mount option. Few fragments. The second paragraph applies to SD

Re: Btrfs/SSD

On Tue, 18 Apr 2017 03:23:13 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Without reading the links... > > Are you /sure/ it's /all/ ssds currently on the market? Or are you > thinking narrowly, those actually sold as ssds? > > Because all I've read (and I admit I may not actually be

Re: Btrfs/SSD

Roman Mamedov posted on Mon, 17 Apr 2017 23:24:19 +0500 as excerpted: > Days are long gone since the end user had to ever think about device > lifetimes with SSDs. Refer to endurance studies such as > http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre- all-dead >

Re: Btrfs/SSD

On 04/17/2017 09:22 PM, Imran Geriskovan wrote: > [...] > > Going over the thread following questions come to my mind: > > - What exactly does btrfs ssd option does relative to plain mode? There's quite an amount of information in the the very recent threads: - "About free

Re: Btrfs/SSD

On Mon, Apr 17, 2017 at 1:26 PM, Austin S. Hemmelgarn wrote: > On 2017-04-17 14:34, Chris Murphy wrote: >> Nope. The first paragraph applies to NVMe machine with ssd mount >> option. Few fragments. >> >> The second paragraph applies to SD Card machine with ssd_spread mount

Re: Btrfs/SSD

On 2017-04-17 14:34, Chris Murphy wrote: On Mon, Apr 17, 2017 at 11:13 AM, Austin S. Hemmelgarn wrote: What is a high end SSD these days? Built-in NVMe? One with a good FTL in the firmware. At minimum, the good Samsung EVO drives, the high quality Intel ones, and the

Re: Btrfs/SSD

otherwise inconvenient or not needed) just to save the SSD lifetime. Going over the thread following questions come to my mind: - What exactly does btrfs ssd option does relative to plain mode? - Most(all?) SSDs employ wear leveling. Isn't it? That is they are constrantly remapping their b

Re: Btrfs/SSD

On Mon, Apr 17, 2017 at 11:13 AM, Austin S. Hemmelgarn wrote: >> What is a high end SSD these days? Built-in NVMe? > > One with a good FTL in the firmware. At minimum, the good Samsung EVO > drives, the high quality Intel ones, and the Crucial MX series, but probably >

Re: Btrfs/SSD

On Mon, 17 Apr 2017 07:53:04 -0400 "Austin S. Hemmelgarn" wrote: > General info (not BTRFS specific): > * Based on SMART attributes and other factors, current life expectancy > for light usage (normal desktop usage) appears to be somewhere around > 8-12 years depending on

Re: Btrfs/SSD

On 2017-04-17 12:58, Chris Murphy wrote: On Mon, Apr 17, 2017 at 5:53 AM, Austin S. Hemmelgarn wrote: Regarding BTRFS specifically: * Given my recently newfound understanding of what the 'ssd' mount option actually does, I'm inclined to recommend that people who are

Re: Btrfs/SSD

On Mon, Apr 17, 2017 at 5:53 AM, Austin S. Hemmelgarn wrote: > Regarding BTRFS specifically: > * Given my recently newfound understanding of what the 'ssd' mount option > actually does, I'm inclined to recommend that people who are using high-end > SSD's _NOT_ use it as it

Re: Btrfs/SSD

On 2017-04-14 07:02, Imran Geriskovan wrote: Hi, Sometime ago we had some discussion about SSDs. Within the limits of unknown/undocumented device infos, we loosely had covered data retension capability/disk age/life time interrelations, (in?)effectiveness of btrfs dup on SSDs, etc.. Now, as

Btrfs/SSD

Hi, Sometime ago we had some discussion about SSDs. Within the limits of unknown/undocumented device infos, we loosely had covered data retension capability/disk age/life time interrelations, (in?)effectiveness of btrfs dup on SSDs, etc.. Now, as time passed and with some accumulated experience

Re: [PATCH] btrfs: SSD related mount option dependency rework.

not to repeat them in btrfs.txt. Thanks, Qu Original Message Subject: [PATCH] btrfs: SSD related mount option dependency rework. From: Qu Wenruo quwen...@cn.fujitsu.com To: linux-btrfs@vger.kernel.org Date: 2014年08月01日 11:27 According to Documentations/filesystem/btrfs.txt, ssd

Re: [PATCH] btrfs: SSD related mount option dependency rework.

Hi Qu, (2014/08/01 12:27), Qu Wenruo wrote: According to Documentations/filesystem/btrfs.txt, ssd/ssd_spread/nossd has their own dependency(See below), but only ssd_spread implying ssd is implemented. ssd_spread implies ssd, conflicts nossd. ssd conflicts nossd. nossd conflicts ssd and

[PATCH] btrfs: SSD related mount option dependency rework.

According to Documentations/filesystem/btrfs.txt, ssd/ssd_spread/nossd has their own dependency(See below), but only ssd_spread implying ssd is implemented. ssd_spread implies ssd, conflicts nossd. ssd conflicts nossd. nossd conflicts ssd and ssd_spread. This patch adds ssd{,_spread} confliction

BTRFS, SSD and single metadata

Hi, I created a BTRFS filesytem over LVM over LUKS encryption on an SSD [yes, I know...], and I noticed that the FS got created with metadata in DUP mode, contrary to what man mkfs.btrfs says for SSDs - it would be supposed to be SINGLE... Well I don't know if my system didn't identify the

Re: BTRFS, SSD and single metadata

On 2014-06-16 03:54, Swâmi Petaramesh wrote: Hi, I created a BTRFS filesytem over LVM over LUKS encryption on an SSD [yes, I know...], and I noticed that the FS got created with metadata in DUP mode, contrary to what man mkfs.btrfs says for SSDs - it would be supposed to be SINGLE...

Re: BTRFS, SSD and single metadata

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

Re: BTRFS, SSD and single metadata

On 2014-06-16 07:18, Swâmi Petaramesh wrote: 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

Re: BTRFS, SSD and single metadata

On Mon, 16 Jun 2014 07:23:14 Austin S Hemmelgarn wrote: I'd personally stay with the DUP profile, but then that's just me being paranoid. You will almost certainly get better performance using the SINGLE profile instead of DUP, but this is mostly due to it requiring fewer blocks to be

Re: BTRFS, SSD and single metadata

Swâmi Petaramesh posted on Mon, 16 Jun 2014 09:54:01 +0200 as excerpted: I created a BTRFS filesytem over LVM over LUKS encryption on an SSD [yes, I know...], and I noticed that the FS got created with metadata in DUP mode, contrary to what man mkfs.btrfs says for SSDs - it would be supposed

Re: BTRFS, SSD and single metadata

Le lundi 16 juin 2014, 12:16:33 Duncan a écrit : Does btrfs automatically add the ssd mount option or do you have to add it? If you have to add it, that means btrfs isn't detecting the ssd, First time I mounted the freshly created filesystem, it actually added the ssd option by itself. Thus

BTRFS SSD RAID 1: Does it trim on both devices? :)

Hi! Since a few days this ThinkPad T520 has 780 GB SSD capacity. The 300 GB of the Intel SSD 320 were almost full and that 480 GB Crucial m500 mSATA SSD was cheap enough to just buy it. I created a new logical volume for big and not that often changed files that is just on the msata and moved

Re: BTRFS SSD

Yuehai Xu wrote (ao): So, is it a bottleneck in the case of SSD since the cost for over write is very high? For every write, I think the superblocks should be overwritten, it might be much more frequent than other common blocks in SSD, even though SSD will do wear leveling inside by its FTL.

Re: BTRFS SSD

On 29/09/2010 23:31, Yuehai Xu wrote: On Wed, Sep 29, 2010 at 3:59 PM, Sean Bartellwingedtachik...@gmail.com wrote: On Wed, Sep 29, 2010 at 02:45:29PM -0400, Yuehai Xu wrote: On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartellwingedtachik...@gmail.com wrote: On Wed, Sep 29, 2010 at 11:30:14AM

Re: BTRFS SSD

On Thu, Sep 30, 2010 at 3:51 AM, David Brown da...@westcontrol.com wrote: On 29/09/2010 23:31, Yuehai Xu wrote: On Wed, Sep 29, 2010 at 3:59 PM, Sean Bartellwingedtachik...@gmail.com  wrote: On Wed, Sep 29, 2010 at 02:45:29PM -0400, Yuehai Xu wrote: On Wed, Sep 29, 2010 at 1:08 PM, Sean

Re: BTRFS SSD

On Thu, Sep 30, 2010 at 3:15 AM, Sander san...@humilis.net wrote: Yuehai Xu wrote (ao): So, is it a bottleneck in the case of SSD since the cost for over write is very high? For every write, I think the superblocks should be overwritten, it might be much more frequent than other common blocks

Re: BTRFS SSD

On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote: I know BTRFS is a kind of Log-structured File System, which doesn't do overwrite. Here is my question, suppose file A is overwritten by A', instead of writing A' to the original place of A, a new place is selected to store it. However,

Re: BTRFS SSD

Hi, On Wed, Sep 29, 2010 at 11:37 AM, Dipl.-Ing. Michael Niederle mniede...@gmx.at wrote: Hi Yuehai! I tested nilfs2 and btrfs for the use with flash based pen drives. nilfs2 performed incredibly well as long as there were enough free blocks. But the garbage collector of nilfs used too much

Re: BTRFS SSD

On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell wingedtachik...@gmail.com wrote: On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote: I know BTRFS is a kind of Log-structured File System, which doesn't do overwrite. Here is my question, suppose file A is overwritten by A', instead of

Re: BTRFS SSD

On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell wingedtachik...@gmail.com wrote: In btrfs, this is solved by doing the same thing for the inode--a new place for the leaf holding the inode is chosen. Then the parent of the leaf must point to the new position of the leaf, so the parent is moved,

Re: BTRFS SSD

On Wed, Sep 29, 2010 at 02:45:29PM -0400, Yuehai Xu wrote: On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell wingedtachik...@gmail.com wrote: On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote: I know BTRFS is a kind of Log-structured File System, which doesn't do overwrite. Here is my

Re: BTRFS SSD

On Wed, Sep 29, 2010 at 03:39:07PM -0400, Aryeh Gregor wrote: On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell wingedtachik...@gmail.com wrote: In btrfs, this is solved by doing the same thing for the inode--a new place for the leaf holding the inode is chosen. Then the parent of the leaf

Re: BTRFS SSD

On Wed, Sep 29, 2010 at 3:59 PM, Sean Bartell wingedtachik...@gmail.com wrote: On Wed, Sep 29, 2010 at 02:45:29PM -0400, Yuehai Xu wrote: On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell wingedtachik...@gmail.com wrote: On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote: I know BTRFS

Btrfs SSD autodetection and mount options

Hello everyone, A quick update on the btrfs SSD modes. The pull request I just to Linus includes autodetection of ssd devices based on the queue rotating flag. You can see this for your devices in /sys/block/xxx/queue/rotating If all the devices in your FS have a 0 in the rotating flag, btrfs