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. bcache-writearound does not cache writes
> > > on 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
Always - 13
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
> > > bcache-writeback. But t
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 storage with fast access. I
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
>> sector, BS - bad sect
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
> > > traditional filesystems fro
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 itsel
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, I'm
> > using bcache su
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 wrote:
> [...]
> >>
> >> I'm trying to have a proper understanding of
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
> > space is usually at the far
> 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 r
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. =:^)
(I'm currently still o
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
option actually does, I'm inclined to recommend that pe
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 store 500GB of data that you
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
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
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 have only 30GB stored on
notified of as much as
> possible disk 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 t
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
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 pool.
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 genera
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 which
> 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 relia
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 which
> > failed suddenly and unexpected, and
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 more data access, everyth
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 k
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 good as possible.
Yea
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 still on quarter-TB generation ss
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 inclined to recommend that people who are
> > using high-e
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
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
> a
On Mon, Apr 17, 2017 at 4:55 PM, Hans van Kranenburg
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 ssd option does relative to plain mod
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 _NOT_ use it as it will
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 _NOT_ use it as it will heavily increase
> fragmentation and wil
fetime.
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, whereas normal mode goes
for 64k alignment.
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 to not fsync at all, a
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 Card machine with ssd_spr
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 cur
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
> http://ssdendu
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
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
>> option. Many fragmen
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 Crucial MX series, but
) 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 blocks under the hood. So isn't it
mean
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
> some others. My choice of
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 specifics of usage (as
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 using high-end
SSD's _NOT_
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 will heavily increase f
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 time
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 on
ike not to repeat them in
btrfs.txt.
Thanks,
Qu
Original Message
Subject: [PATCH] btrfs: SSD related mount option dependency rework.
From: Qu Wenruo
To:
Date: 2014年08月01日 11:27
According to Documentations/filesystem/btrfs.txt, ssd/ssd_spread/nossd
has their own dependency(See b
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
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
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. T
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 s
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 encr
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//queue/rotational, if that is 1 it knows
>> that the device isn't a SSD. I believe that LVM passes
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//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, b
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
> "SI
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
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 all
Yuehai Xu wrote (ao):
> On Thu, Sep 30, 2010 at 3:15 AM, Sander 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
On Thu, Sep 30, 2010 at 3:15 AM, Sander 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
>> in SSD, e
On Thu, Sep 30, 2010 at 3:51 AM, David Brown wrote:
> On 29/09/2010 23:31, Yuehai Xu wrote:
>>
>> On Wed, Sep 29, 2010 at 3:59 PM, Sean Bartell
>> 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
wrote:
>
>
On 29/09/2010 23:31, Yuehai Xu wrote:
On Wed, Sep 29, 2010 at 3:59 PM, Sean Bartell 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 wrote:
On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote:
I know BTRFS is a kind of Log
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
On Wed, Sep 29, 2010 at 3:59 PM, Sean Bartell 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
>> 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,
On Wed, Sep 29, 2010 at 03:39:07PM -0400, Aryeh Gregor wrote:
> On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell
> 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 ne
On Wed, Sep 29, 2010 at 02:45:29PM -0400, Yuehai Xu wrote:
> On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell
> 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, suppo
On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell 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,
> and the parent's parent
On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell 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 writing A' to the origin
Hi,
On Wed, Sep 29, 2010 at 11:37 AM, Dipl.-Ing. Michael Niederle
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 IO-bandwid
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. Howev
Hi,
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, we know that the address of a file
should be recorded in i
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
On the call, we talked briefly about trying to get some access to high
speed SSD's for btrfs testing. I did not see online prices for STEC
which is one high end part we mentioned, but I did see that Rocketdisk
has 2.5 & 3.5 inch S-ATA drives that claim 19,000 IOPS.
The affordable ones (say $
75 matches
Mail list logo
