ssd optimised mode

ssd optimised mode

[srimugunthan dhandapani]

hi all,
I would like to know what are the ssd specific optimisations in btrfs .
I read from the archives that

"mount -o ssd option, which clusters file data writes together regardless of
the directory the files belong to.  There are a number of other performance
tweaks for SSD, aimed at clustering metadata and data writes to better take
advantage of the hardware"
Also I read that there are some allocator changes specific to ssd. I
would like to know what these changes are.

I tried to see the  v 0.17 code  to understand what ssd specific changes are.
I saw that the SSD option was used in two places in function
find_free_extent and in function btrfs_defrag_leaves.
I couldn't gather much information from the code.
So can somebody help me understand the optimisations and changes in btrfs.
are any documentation or reading material available?
Thanks in advance for helping,
Mugunthan

Re: ssd optimised mode

[Josef Bacik]

On Fri, Feb 20, 2009 at 04:56:55PM +0530, srimugunthan dhandapani wrote:
> hi all,
> I would like to know what are the ssd specific optimisations in btrfs .
> I read from the archives that
> 
> "mount -o ssd option, which clusters file data writes together regardless of
> the directory the files belong to.  There are a number of other performance
> tweaks for SSD, aimed at clustering metadata and data writes to better take
> advantage of the hardware"
> Also I read that there are some allocator changes specific to ssd. I
> would like to know what these changes are.
> 
> I tried to see the  v 0.17 code  to understand what ssd specific changes are.
> I saw that the SSD option was used in two places in function
> find_free_extent and in function btrfs_defrag_leaves.
> I couldn't gather much information from the code.
> So can somebody help me understand the optimisations and changes in btrfs.
> are any documentation or reading material available?
> Thanks in advance for helping,

So really the only thing that changes with SSD is that we keep track of the last
place we allocated for data, and start looking from there again.  Since there is
no seek penalty we can just be dumb in the allocator and use up space
sequentially regardless of the file instead of trying to group allocations for
the file/dir.  Thanks,

Josef

Re: ssd optimised mode

[Chris Mason]

On Fri, 2009-02-20 at 11:01 -0500, Josef Bacik wrote:
> On Fri, Feb 20, 2009 at 04:56:55PM +0530, srimugunthan dhandapani wrote:
> > hi all,
> > I would like to know what are the ssd specific optimisations in btrfs .
> > I read from the archives that
> > 
> > "mount -o ssd option, which clusters file data writes together regardless of
> > the directory the files belong to.  There are a number of other performance
> > tweaks for SSD, aimed at clustering metadata and data writes to better take
> > advantage of the hardware"
> > Also I read that there are some allocator changes specific to ssd. I
> > would like to know what these changes are.
> > 
> > I tried to see the  v 0.17 code  to understand what ssd specific changes are.
> > I saw that the SSD option was used in two places in function
> > find_free_extent and in function btrfs_defrag_leaves.
> > I couldn't gather much information from the code.
> > So can somebody help me understand the optimisations and changes in btrfs.
> > are any documentation or reading material available?
> > Thanks in advance for helping,
> 
> So really the only thing that changes with SSD is that we keep track of the last
> place we allocated for data, and start looking from there again.  Since there is
> no seek penalty we can just be dumb in the allocator and use up space
> sequentially regardless of the file instead of trying to group allocations for
> the file/dir.  Thanks,

We already do this with metadata, but the ssd mode makes the metadata
cluster that we try to allocate larger now.  This change was made based
on benchmarks with an SSD that is bad at random writes, and it made a
significant difference for metadata writes.

The short answer is that in ssd mode we don't try to avoid random reads.

-chris

Re: ssd optimised mode

[Dmitri Nikulin]

On Sat, Feb 21, 2009 at 3:30 AM, Chris Mason <chris.mason@oracle.com> wrote:
> The short answer is that in ssd mode we don't try to avoid random reads.

In the ideal future where SSDs can be run without a flimsy hardware
FTL, and btrfs can use something like ubi directly, would SSD mode
also be able to enable more intelligent wear levelling and safer use
of eraseblocks?

I've read that one of the potentially crippling limitations of ZFS is
that even its reliability features depend largely on being able to
perform atomic writes, which are currently impossible (?) on flash
media where a block has to be erased before it can be updated, clearly
not an atomic operation. Is there any solution to this that doesn't
depend on a battery backup? Clearly it's not something a filesystem
can practically solve.

--
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia

Re: ssd optimised mode

[Steven Pratt]

Dmitri Nikulin wrote:
> On Sat, Feb 21, 2009 at 3:30 AM, Chris Mason <chris.mason@oracle.com> wrote:
>   
>> The short answer is that in ssd mode we don't try to avoid random reads.
>>     
>
> In the ideal future where SSDs can be run without a flimsy hardware
> FTL, and btrfs can use something like ubi directly, would SSD mode
> also be able to enable more intelligent wear levelling and safer use
> of eraseblocks?
>
> I've read that one of the potentially crippling limitations of ZFS is
> that even its reliability features depend largely on being able to
> perform atomic writes, which are currently impossible (?) on flash
> media where a block has to be erased before it can be updated, clearly
> not an atomic operation. Is there any solution to this that doesn't
> depend on a battery backup? Clearly it's not something a filesystem
> can practically solve.
>
>   
Well this is not really a problem with enterprise class SSD drives.  
They almost all use super capacitors to be able to have enough power to 
flush the dram cache to the nand chips without the need for any external 
battery backup.

Steve
> --
> Dmitri Nikulin
>
> Centre for Synchrotron Science
> Monash University
> Victoria 3800, Australia
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: ssd optimised mode

[Dmitri Nikulin]

On Mon, Feb 23, 2009 at 4:44 AM, Steven Pratt <slpratt@austin.ibm.com> wrote:
> Well this is not really a problem with enterprise class SSD drives.  They
> almost all use super capacitors to be able to have enough power to flush the
> dram cache to the nand chips without the need for any external battery
> backup.

That's excellent, but until consumer-level drives have the same
feature, the fact remains that consumer SSDs are a net loss in
reliability compared to consumer rotating disks, where by their
marketing material they should be a gain. That's an issue with SSDs in
general and certainly no fault of btrfs, I'm just curious if there's
anything that can be done in a filesystem to minimise the damage of a
lost eraseblock. In fact, will metadata mirroring solve this for us
already, or does that still not handle failures in some "critical"
blocks at the root of a filesystem?

-- 
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia

Re: ssd optimised mode

[Dongjun Shin]

On Mon, Feb 23, 2009 at 10:06 AM, Dmitri Nikulin <dnikulin@gmail.com> wrote:
> On Mon, Feb 23, 2009 at 4:44 AM, Steven Pratt <slpratt@austin.ibm.com> wrote:
>> Well this is not really a problem with enterprise class SSD drives.  They
>> almost all use super capacitors to be able to have enough power to flush the
>> dram cache to the nand chips without the need for any external battery
>> backup.
>
> That's excellent, but until consumer-level drives have the same
> feature, the fact remains that consumer SSDs are a net loss in
> reliability compared to consumer rotating disks, where by their
> marketing material they should be a gain. That's an issue with SSDs in
> general and certainly no fault of btrfs, I'm just curious if there's
> anything that can be done in a filesystem to minimise the damage of a
> lost eraseblock. In fact, will metadata mirroring solve this for us
> already, or does that still not handle failures in some "critical"
> blocks at the root of a filesystem?
>

A well-designed SSD should survive power cycling and should provide atomicity
of flush operation regardless of the underlying flash operations. I don't expect
that users of SSD have different requirements about atomicity.

The existence of super capacitors may help increasing the performance
as well as the reliability of data. However, that should not be the necessary
condition for the atomicity.

-- 
Dongjun

Re: ssd optimised mode

[Dmitri Nikulin]

On Mon, Feb 23, 2009 at 12:22 PM, Dongjun Shin <djshin90@gmail.com> wrote:
> A well-designed SSD should survive power cycling and should provide atomicity
> of flush operation regardless of the underlying flash operations. I don't expect
> that users of SSD have different requirements about atomicity.

Well that's my point, it "should" provide atomicity, but is this the
case for consumer SSDs? It is certainly NOT the case for cheap
USB-based flash media and AFAIK not for CF either.

-- 
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia

Re: ssd optimised mode

[Dongjun Shin]

On Mon, Feb 23, 2009 at 11:33 AM, Dmitri Nikulin <dnikulin@gmail.com> wrote:
> On Mon, Feb 23, 2009 at 12:22 PM, Dongjun Shin <djshin90@gmail.com> wrote:
>> A well-designed SSD should survive power cycling and should provide atomicity
>> of flush operation regardless of the underlying flash operations. I don't expect
>> that users of SSD have different requirements about atomicity.
>
> Well that's my point, it "should" provide atomicity, but is this the
> case for consumer SSDs? It is certainly NOT the case for cheap
> USB-based flash media and AFAIK not for CF either.
>

AFAIK, all enterprise and consumer SSDs have atomicity requirements
because they're designed to replace the HDD without changes to the OS.

USB or any kind of flash-based cards have different requirements.
They're optimized for cost and the priority for the atomicity is low.
Moreover, they can be plugged out without prior notice to OS.

-- 
Dongjun

Re: ssd optimised mode

[Seth Huang]

On Mon, Feb 23, 2009 at 12:22 PM, Dongjun Shin <djshin90@gmail.com> wrote:
> A well-designed SSD should survive power cycling and should provide atomicity
> of flush operation regardless of the underlying flash operations. I don't expect
> that users of SSD have different requirements about atomicity.

A reliable system should be based on the assumption that the underlying parts are unreliable. Therefore, we should do as much as possible to make sure the reliability in our filesystem instead of leaning on the SSDs.

-- 
Seth Huang

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ssd optimised mode

[Dmitri Nikulin]

On Mon, Feb 23, 2009 at 2:17 PM, Seth Huang <seth.hg@gmail.com> wrote:
> On Mon, Feb 23, 2009 at 12:22 PM, Dongjun Shin <djshin90@gmail.com> wrote:
>> A well-designed SSD should survive power cycling and should provide atomicity
>> of flush operation regardless of the underlying flash operations. I don't expect
>> that users of SSD have different requirements about atomicity.
>
> A reliable system should be based on the assumption that the underlying parts are unreliable. Therefore, we should do as much as possible to make sure the reliability in our filesystem instead of leaning on the SSDs.

I generally agree with this approach, however, it would clearly have a
performance penalty. If possible it should be optional so that, on a
reliable media, the hardware can do the hard work and software can
perform well. But it might be too much to ask that btrfs support
mkfs/mount options for every distinct class of storage (rotating, bad
SSD, good SSD, USB flash, holographic cube, electron spin, etc.).

-- 
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia

Re: ssd optimised mode

[Oliver Mattos]

Hi,

While this sounds nice in practice, in reality since eraseblocks are 
generally very large, and with hardware based block remapping (FTL), you can 
never be sure which data blocks are at risk when re-writing just one block. 
There is a good chance that rewriting one block of data somewhere will wipe 
out a block of data at a totally different location of the disk.

Since the filesystem has no understanding of the hardware FTL, there isn't 
much that can be done about this at the filesystem level.

The only thing that could be done is metadata mirroring on the same disk, 
but I suspect even that would only marginally improve reliability, since 
both copies of the metadata are likely to be written to storage at nearly 
the same time, they are quite likely to be re-mapped into the same block, 
and then if you loose one, you loose both.

The solution to this is twofold:
1 :- filesystems should be able to detect when a non-atomic write has 
corrupted the filesystem and tell the user - eg. "Filesystem corruption 
found, Likley hardware malfunction detected"  (since with a fs like btrfs, 
when all big software bugs are resolved, the only thing that can cause disk 
corruption are hardware issues)

2 :- Someone who feels this is close to their heart needs to test every big 
brand of SSD and name and shame those where writes are non-atomic - as soon 
as you get this publicised that certain brands of SSD put data at risk, the 
manufacturer will be very fast at resolving it.


----- Original Message ----- 
From: "Seth Huang" <seth.hg@gmail.com>
To: <linux-btrfs@vger.kernel.org>
Sent: Monday, February 23, 2009 3:17 AM
Subject: Re: ssd optimised mode


> On Mon, Feb 23, 2009 at 12:22 PM, Dongjun Shin <djshin90@gmail.com> wrote:
>> A well-designed SSD should survive power cycling and should provide 
>> atomicity
>> of flush operation regardless of the underlying flash operations. I don't 
>> expect
>> that users of SSD have different requirements about atomicity.
>
> A reliable system should be based on the assumption that the underlying 
> parts are unreliable. Therefore, we should do as much as possible to make 
> sure the reliability in our filesystem instead of leaning on the SSDs.
>
> -- 
> Seth Huang
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: ssd optimised mode

[Martin K. Petersen]

>>>>> "Dmitri" == Dmitri Nikulin <dnikulin@gmail.com> writes:

Dmitri> That's excellent, but until consumer-level drives have the same
Dmitri> feature, the fact remains that consumer SSDs are a net loss in
Dmitri> reliability compared to consumer rotating disks,

My SSD testing has not been very promising in the data integrity
department.  I've got a couple of drives here which end up corrupting
stuff every time they are reset or lose power.

"Stuff" in this case is on the order of megabytes, not a few sectors
like on spinning media.  With disk drives the risk of garbling unrelated
files is there but relatively small.  On SSDs it's much higher because
of the big blocking and the high latency erase/rewrite cycle.  In
several cases I've lost system binaries that obviously weren't being
written when I crashed the system.  In one case I even lost all of
/sbin.


Dmitri> I'm just curious if there's anything that can be done in a
Dmitri> filesystem to minimise the damage of a lost eraseblock.

The problem is that we have no way of knowing what's inside each erase
block.  We don't even know how big the erase block is.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: ssd optimised mode

[Claudio Martins]

On Monday 23 February 2009, Martin K. Petersen wrote:
> "Stuff" in this case is on the order of megabytes, not a few sectors
> like on spinning media.  With disk drives the risk of garbling unrela=
ted
> files is there but relatively small.  On SSDs it's much higher becaus=
e
> of the big blocking and the high latency erase/rewrite cycle.  In
> several cases I've lost system binaries that obviously weren't being
> written when I crashed the system.  In one case I even lost all of
> /sbin.
>

 What brand of SSDs are we talking about? What filesystems did you expe=
riment=20
with?

 Best regards

Cl=C3=A1udio

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ssd optimised mode

[Martin K. Petersen]

>>>>> "Claudio" == Claudio Martins <ctpm@ist.utl.pt> writes:

Claudio> What brand of SSDs are we talking about?

I tested two different products that both exhibited poor behavior during
frequent resets/power cycles.  I can't really disclose details but rest
assured I'm working with the vendors in question to get this fixed.
Just last Friday I received a couple of updated drives that appear to
work correctly.  But I haven't tested them extensively yet.


Claudio> What filesystems did you experiment with?

Some tests were done with ext3 but most tests were done using my own
integrity checking tooling and/or dt.

In the filesystem case it was trivial to map out the affected files in
debugfs and correlate those to a logical region on the disk.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: ssd optimised mode

[Chris Mason]

On Sun, 2009-02-22 at 12:07 +1100, Dmitri Nikulin wrote:
> On Sat, Feb 21, 2009 at 3:30 AM, Chris Mason <chris.mason@oracle.com> wrote:
> > The short answer is that in ssd mode we don't try to avoid random reads.
> 
> In the ideal future where SSDs can be run without a flimsy hardware
> FTL, and btrfs can use something like ubi directly, would SSD mode
> also be able to enable more intelligent wear levelling and safer use
> of eraseblocks?

I think this kind of future is less and less likely.  SSD makers are
going to differentiate themselves via their FTL, and they are not going
to give the OS the chance to mess around with the flash directly.

There will surely be exceptions, but I don't think we're going to find
them in a dell any time soon.

> 
> I've read that one of the potentially crippling limitations of ZFS is
> that even its reliability features depend largely on being able to
> perform atomic writes, which are currently impossible (?) on flash
> media where a block has to be erased before it can be updated, clearly
> not an atomic operation. Is there any solution to this that doesn't
> depend on a battery backup? Clearly it's not something a filesystem
> can practically solve.

I'm sure that some early flash drives got this wrong, but the crummy
drives will eventually drop out of the market as the reliable ones gain
traction.

-chris

Re: ssd optimised mode

[Dmitri Nikulin]

On Tue, Feb 24, 2009 at 1:33 AM, Chris Mason <chris.mason@oracle.com> wrote:
> On Sun, 2009-02-22 at 12:07 +1100, Dmitri Nikulin wrote:
>> On Sat, Feb 21, 2009 at 3:30 AM, Chris Mason <chris.mason@oracle.com> wrote:
>> > The short answer is that in ssd mode we don't try to avoid random reads.
>>
>> In the ideal future where SSDs can be run without a flimsy hardware
>> FTL, and btrfs can use something like ubi directly, would SSD mode
>> also be able to enable more intelligent wear levelling and safer use
>> of eraseblocks?
>
> I think this kind of future is less and less likely.  SSD makers are
> going to differentiate themselves via their FTL, and they are not going
> to give the OS the chance to mess around with the flash directly.
>
> There will surely be exceptions, but I don't think we're going to find
> them in a dell any time soon.

Already SanDisk are offering a proprietary "Extreme FFS" (perhaps even
based on Unix FFS) for Windows Vista only.
http://www.technewsworld.com/story/65072.html?wlc=1235097496&wlc=1235434234
It is not clear whether this is purely a filesystem which could work
on any SSD, but I think it is much more likely it has an FTL bypass
that lets it get higher performance than any FTLed filesystem. <RMS>It
is proprietary from the ground up and products like these could undo
the decades of standardisation and interoperability that have made
hard disks and their controllers a commodity. </RMS>

> I'm sure that some early flash drives got this wrong, but the crummy
> drives will eventually drop out of the market as the reliable ones gain
> traction.

I'm glad to see this is the trend. I would like nothing more than to
not have to care about the SSD being an SSD. Right now it seems you do
have to care to get good performance and longevity, but if you can
just treat them as a regular disk for the most part, that is a very
valuable product even worth the exorbitant price tags. Personally I'm
happy as long as I can make one big PV (or RAID0 then a PV) and have
that perform well with minimum tweaking. If I can use btrfs as a RAID
and volume manager and have that perform even better on the SSD, all
the better :)

-- 
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia

Re: ssd optimised mode

[Dongjun Shin]

On Tue, Feb 24, 2009 at 9:16 AM, Dmitri Nikulin <dnikulin@gmail.com> wrote:
>
> Already SanDisk are offering a proprietary "Extreme FFS" (perhaps even
> based on Unix FFS) for Windows Vista only.
> http://www.technewsworld.com/story/65072.html?wlc=1235097496&wlc=1235434234
> It is not clear whether this is purely a filesystem which could work
> on any SSD, but I think it is much more likely it has an FTL bypass
> that lets it get higher performance than any FTLed filesystem. <RMS>It
> is proprietary from the ground up and products like these could undo
> the decades of standardisation and interoperability that have made
> hard disks and their controllers a commodity. </RMS>
>

I heard that ExtremeFFS is a firmware or FTL technology although
it sounds like a filesystem.

-- 
Dongjun

Re: ssd optimised mode

[Martin K. Petersen]

>>>>> "Dmitri" == Dmitri Nikulin <dnikulin@gmail.com> writes:

Dmitri> Already SanDisk are offering a proprietary "Extreme FFS"
Dmitri> (perhaps even based on Unix FFS) for Windows Vista only.

Extreme FFS is SanDisk's next generation FTL/firmware.  It's not a
filesystem that plugs into the OS.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: ssd optimised mode

[Dmitri Nikulin]

On Tue, Feb 24, 2009 at 1:32 PM, Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>>>>>> "Dmitri" == Dmitri Nikulin <dnikulin@gmail.com> writes:
>
> Dmitri> Already SanDisk are offering a proprietary "Extreme FFS"
> Dmitri> (perhaps even based on Unix FFS) for Windows Vista only.
>
> Extreme FFS is SanDisk's next generation FTL/firmware.  It's not a
> filesystem that plugs into the OS.

If that's the case, why is it marketed for Windows Vista only, and
referring to filesystem features like marking unused blocks? Surely if
it was at the device level it would be OS-neutral, and marketed as
such.

-- 
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia

Re: ssd optimised mode

[Dongjun Shin]

On Tue, Feb 24, 2009 at 12:53 PM, Dmitri Nikulin <dnikulin@gmail.com> w=
rote:
> On Tue, Feb 24, 2009 at 1:32 PM, Martin K. Petersen
> <martin.petersen@oracle.com> wrote:
>>>>>>> "Dmitri" =3D=3D Dmitri Nikulin <dnikulin@gmail.com> writes:
>>
>> Dmitri> Already SanDisk are offering a proprietary "Extreme FFS"
>> Dmitri> (perhaps even based on Unix FFS) for Windows Vista only.
>>
>> Extreme FFS is SanDisk's next generation FTL/firmware. =A0It's not a
>> filesystem that plugs into the OS.
>
> If that's the case, why is it marketed for Windows Vista only, and
> referring to filesystem features like marking unused blocks? Surely i=
f
> it was at the device level it would be OS-neutral, and marketed as
> such.
>

It's marketed for Windows 7 and Windows 7 has feature that send down
trim/discard info to the storage.

Anyway, Linux support for trim is under way [1].

--=20
Dongjun

[1] http://git.kernel.org/?p=3Dlinux/kernel/git/willy/ssd.git;a=3Dshort=
log;h=3Dtrim-20090212
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ssd optimised mode

[Martin K. Petersen]

>>>>> "Dmitri" == Dmitri Nikulin <dnikulin@gmail.com> writes:

Dmitri> If that's the case, why is it marketed for Windows Vista only,
Dmitri> and referring to filesystem features like marking unused blocks?
Dmitri> Surely if it was at the device level it would be OS-neutral, and
Dmitri> marketed as such.

The article you posted references some benchmarketing numbers involving
Vista.  That does not imply it's a Windows-only product.

	http://en.wikipedia.org/wiki/ExtremeFFS

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: ssd optimised mode

[Dmitri Nikulin]

On Tue, Feb 24, 2009 at 3:10 PM, Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>>>>>> "Dmitri" =3D=3D Dmitri Nikulin <dnikulin@gmail.com> writes:
>
> Dmitri> If that's the case, why is it marketed for Windows Vista only=
,
> Dmitri> and referring to filesystem features like marking unused bloc=
ks?
> Dmitri> Surely if it was at the device level it would be OS-neutral, =
and
> Dmitri> marketed as such.
>
> The article you posted references some benchmarketing numbers involvi=
ng
> Vista. =C2=A0That does not imply it's a Windows-only product.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0http://en.wikipedia.org/wiki/ExtremeFFS

So it seems. I misread the marketing material, and I'm very relieved
that Linux will benefit just as much from the improvement, indeed
probably better. Thank you very much for correcting me, Martin and
Dongjun.


--=20
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ssd optimised mode

[Wes Felter]

Dmitri Nikulin wrote:

> In the ideal future where SSDs can be run without a flimsy hardware
> FTL

I don't think this is likely at all for the same reasons Chris gave.

> I've read that one of the potentially crippling limitations of ZFS is
> that even its reliability features depend largely on being able to
> perform atomic writes, which are currently impossible (?) on flash
> media where a block has to be erased before it can be updated, clearly
> not an atomic operation. Is there any solution to this that doesn't
> depend on a battery backup?

A COW write to a pre-erased block should be atomic. See TxFlash: 
http://storagemojo.com/2009/01/17/transflash/

Wes Felter - wesley@felter.org