> "et" == Erik Trimble writes:
et> Probably, the smart thing to push for is inclusion of some new
et> command in the ATA standard (in a manner like TRIM). Likely
et> something that would return both native Block and Page sizes
et> upon query.
that would be the *sane* thing t
> "ah" == Al Hopper writes:
ah> The main issue is that most flash devices support 128k byte
ah> pages, and the smallest "chunk" (for want of a better word) of
ah> flash memory that can be written is a page - or 128kb. So if
ah> you have a write to an SSD that only changes 1 b
Yet another way to thin-out the backing devices for a zpool on a
thin-provisioned storage host, today: resilver.
If your zpool has some redundancy across the SAN backing LUNs, simply
drop and replace one at a time and allow zfs to resilver only the
blocks currently in use onto the replacement LUN
As a further update, I went back and re-read my SSD controller info, and
then did some more Googling.
Turns out, I'm about a year behind on State-of-the-SSD.Eric is
correct on the way current SSDs implement writes (both SLC and MLC), so
I'm issuing a mea-cupla here. The change in implemen
> "dm" == David Magda writes:
dm> 4096 - to-512 blocks
aiui NAND flash has a minimum write size (determiined by ECC OOB bits)
of 2 - 4kB, and a minimum erase size that's much larger. Remapping
cannot abstract away the performance implication of the minimum write
size if you are doing a
Eric D. Midama did a very good job answering this, and I don't have
much to add. Thanks Eric!
On 3 jan 2010, at 07.24, Erik Trimble wrote:
> I think you're confusing erasing with writing.
I am now quite certain that it actually was you who were
confusing those. I hope this discussion has cleare
On Sat, Jan 2 at 22:24, Erik Trimble wrote:
In MLC-style SSDs, you typically have a block size of 2k or 4k.
However, you have a Page size of several multiples of that, 128k
being common, but by no means ubiquitous.
I believe your terminology is crossed a bit. What you call a block is
usually
Erik Trimble wrote:
Ragnar Sundblad wrote:
Yes, there is something to worry about, as you can only
erase flash in large pages - you can not erase them only where
the free data blocks in the Free List are.
I'm not sure that SSDs actually _have_ to erase - they just overwrite
anything there wi
Ragnar Sundblad wrote:
On 3 jan 2010, at 04.19, Erik Trimble wrote:
Let's say I have 4k blocks, grouped into a 128k page. That is, the SSD's
fundamental minimum unit size is 4k, but the minimum WRITE size is 128k. Thus,
32 blocks in a page.
Do you know of SSD disks that have a minim
On 3 jan 2010, at 06.07, Ragnar Sundblad wrote:
> (I don't think they typically merge pages, I believe they rather
> just pick pages with some freed blocks, copies the active blocks
> to the "end" of the disk, and erases the page.)
(And of course you implement wear leveling with the same
mechani
On 3 jan 2010, at 04.19, Erik Trimble wrote:
> Ragnar Sundblad wrote:
>> On 2 jan 2010, at 22.49, Erik Trimble wrote:
>>
>>
>>> Ragnar Sundblad wrote:
>>>
On 2 jan 2010, at 13.10, Erik Trimble wrote
> Joerg Schilling wrote:
> the TRIM command is what is intended f
David Magda wrote:
On Jan 2, 2010, at 16:49, Erik Trimble wrote:
My argument is that the OS has a far better view of the whole data
picture, and access to much higher performing caches (i.e.
RAM/registers) than the SSD, so not only can the OS make far better
decisions about the data and how (
Ragnar Sundblad wrote:
On 2 jan 2010, at 22.49, Erik Trimble wrote:
Ragnar Sundblad wrote:
On 2 jan 2010, at 13.10, Erik Trimble wrote
Joerg Schilling wrote:
the TRIM command is what is intended for an OS to notify the SSD as to which
blocks are deleted/erased, so the SSD's
On Jan 2, 2010, at 1:47 AM, Andras Spitzer wrote:
Mike,
As far as I know only Hitachi is using such a huge chunk size :
"So each vendor’s implementation of TP uses a different block size.
HDS use 42MB on the USP, EMC use 768KB on DMX, IBM allow a variable
size from 32KB to 256KB on the SVC
On Jan 2, 2010, at 16:49, Erik Trimble wrote:
My argument is that the OS has a far better view of the whole data
picture, and access to much higher performing caches (i.e. RAM/
registers) than the SSD, so not only can the OS make far better
decisions about the data and how (and how much of)
On 2 jan 2010, at 22.49, Erik Trimble wrote:
> Ragnar Sundblad wrote:
>> On 2 jan 2010, at 13.10, Erik Trimble wrote
>>> Joerg Schilling wrote:
>>>the TRIM command is what is intended for an OS to notify the SSD as to
>>> which blocks are deleted/erased, so the SSD's internal free list can b
Ragnar Sundblad wrote:
On 2 jan 2010, at 13.10, Erik Trimble wrote
Joerg Schilling wrote:
the TRIM command is what is intended for an OS to notify the SSD as to which blocks are deleted/erased, so the SSD's internal free list can be updated (that is, it allows formerly-in-use blocks to be m
Joerg Schilling wrote:
Erik Trimble wrote:
From ZFS's standpoint, the optimal configuration would be for the SSD
to inform ZFS as to it's PAGE size, and ZFS would use this as the
fundamental BLOCK size for that device (i.e. all writes are in integer
It seems that a command to retr
On 2 jan 2010, at 13.10, Erik Trimble wrote:
> Joerg Schilling wrote:
>> Ragnar Sundblad wrote:
>>
>>
>>> On 1 jan 2010, at 17.28, David Magda wrote:
>>>
>>
>>
Don't really see how things are either hardware specific or dependent.
>>> The inner workings of a SSD flash d
On 2 jan 2010, at 12.43, Joerg Schilling wrote:
> Ragnar Sundblad wrote:
>
>> I certainly agree, but there still isn't much they can do about
>> the WORM-like properties of flash chips, were reading is pretty
>> fast, writing is not to bad, but erasing is very slow and must be
>> done in pretty
Erik Trimble wrote:
> From ZFS's standpoint, the optimal configuration would be for the SSD
> to inform ZFS as to it's PAGE size, and ZFS would use this as the
> fundamental BLOCK size for that device (i.e. all writes are in integer
It seems that a command to retrieve this information does n
Joerg Schilling wrote:
Ragnar Sundblad wrote:
On 1 jan 2010, at 17.28, David Magda wrote:
Don't really see how things are either hardware specific or dependent.
The inner workings of a SSD flash drive is pretty hardware (or
rather vendor) specific, and it may not be a goo
Ragnar Sundblad wrote:
> I certainly agree, but there still isn't much they can do about
> the WORM-like properties of flash chips, were reading is pretty
> fast, writing is not to bad, but erasing is very slow and must be
> done in pretty large pages which also means that active data
> probably
Ragnar Sundblad wrote:
> On 1 jan 2010, at 17.28, David Magda wrote:
> > Don't really see how things are either hardware specific or dependent.
>
> The inner workings of a SSD flash drive is pretty hardware (or
> rather vendor) specific, and it may not be a good idea to move
> any knowledge abou
Mike,
As far as I know only Hitachi is using such a huge chunk size :
"So each vendor’s implementation of TP uses a different block size. HDS use
42MB on the USP, EMC use 768KB on DMX, IBM allow a variable size from 32KB to
256KB on the SVC and 3Par use blocks of just 16KB. The reasons for thi
On 1 jan 2010, at 18.17, Bob Friesenhahn wrote:
> On Fri, 1 Jan 2010, David Magda wrote:
>>
>> It doesn't exist currently because of the behind-the-scenes re-mapping
>> that's being done by the SSD's firmware.
>>
>> While arbitrary to some extent, and "actual" LBA would presumably the number
On 1 jan 2010, at 17.28, David Magda wrote:
> On Jan 1, 2010, at 11:04, Ragnar Sundblad wrote:
>
>> But that would only move the hardware specific and dependent flash
>> chip handling code into the file system code, wouldn't it? What
>> is won with that? As long as the flash chips have larger pa
On 1 jan 2010, at 17.44, Richard Elling wrote:
> On Dec 31, 2009, at 12:59 PM, Ragnar Sundblad wrote:
>> Flash SSDs actually always remap new writes into a
>> only-append-to-new-pages style, pretty much as ZFS does itself.
>> So for a SSD there is no big difference between ZFS and
>> filesystems
On Fri, Jan 1, 2010 at 11:17 AM, Bob Friesenhahn
wrote:
> On Fri, 1 Jan 2010, David Magda wrote:
>>
>> It doesn't exist currently because of the behind-the-scenes re-mapping
>> that's being done by the SSD's firmware.
>>
>> While arbitrary to some extent, and "actual" LBA would presumably the
>> n
On Fri, 1 Jan 2010, David Magda wrote:
It doesn't exist currently because of the behind-the-scenes re-mapping that's
being done by the SSD's firmware.
While arbitrary to some extent, and "actual" LBA would presumably the number
of a particular cell in the SSD.
There seems to be some severe
On Dec 31, 2009, at 12:59 PM, Ragnar Sundblad wrote:
Flash SSDs actually always remap new writes into a
only-append-to-new-pages style, pretty much as ZFS does itself.
So for a SSD there is no big difference between ZFS and
filesystems as UFS, NTFS, HFS+ et al, on the flash level they
all work th
On Jan 1, 2010, at 11:04, Ragnar Sundblad wrote:
But that would only move the hardware specific and dependent flash
chip handling code into the file system code, wouldn't it? What
is won with that? As long as the flash chips have larger pages than
the file system blocks, someone will have to shu
On 1 jan 2010, at 14.14, David Magda wrote:
> On Jan 1, 2010, at 04:33, Ragnar Sundblad wrote:
>
>> I see the possible win that you could always use all the working
>> blocks on the disk, and when blocks goes bad your disk will shrink.
>> I am not sure that is really what people expect, though.
On Jan 1, 2010, at 04:33, Ragnar Sundblad wrote:
I see the possible win that you could always use all the working
blocks on the disk, and when blocks goes bad your disk will shrink.
I am not sure that is really what people expect, though. Apart from
that, I am not sure what the gain would be.
C
On Jan 1, 2010, at 03:30, Eric D. Mudama wrote:
On Thu, Dec 31 at 16:53, David Magda wrote:
Just as the first 4096-byte block disks are silently emulating 4096 -
to-512 blocks, SSDs are currently re-mapping LBAs behind the
scenes. Perhaps in the future there will be a setting to say "no
re
On 31 dec 2009, at 22.53, David Magda wrote:
> On Dec 31, 2009, at 13:44, Joerg Schilling wrote:
>
>> ZFS is COW, but does the SSD know which block is "in use" and which is not?
>>
>> If the SSD did know whether a block is in use, it could erase unused blocks
>> in advance. But what is an "unus
On Thu, Dec 31 at 10:18, Bob Friesenhahn wrote:
There are of course SSDs with hardly any (or no) reserve space, but
while we might be willing to sacrifice an image or two to SSD block
failure in our digital camera, that is just not acceptable for
serious computer use.
Some people are doing se
On Thu, Dec 31 at 16:53, David Magda wrote:
Just as the first 4096-byte block disks are silently emulating 4096 -
to-512 blocks, SSDs are currently re-mapping LBAs behind the scenes.
Perhaps in the future there will be a setting to say "no really, I'm
talking about the /actual/ LBA 123456".
W
On Dec 31, 2009, at 13:44, Joerg Schilling wrote:
ZFS is COW, but does the SSD know which block is "in use" and which
is not?
If the SSD did know whether a block is in use, it could erase unused
blocks
in advance. But what is an "unused block" on a filesystem that
supports
snapshots?
P
On 31 dec 2009, at 19.26, Richard Elling wrote:
> [I TRIMmed the thread a bit ;-)]
>
> On Dec 31, 2009, at 1:43 AM, Ragnar Sundblad wrote:
>> On 31 dec 2009, at 06.01, Richard Elling wrote:
>>>
>>> In a world with copy-on-write and without snapshots, it is obvious that
>>> there will be a lot o
Richard Elling wrote:
> The reason you want TRIM for SSDs is to recover the write speed.
> A freshly cleaned page can be written faster than a dirty page.
> But in COW, you are writing to new pages and not rewriting old
> pages. This is fundamentally different than FAT, NTFS, or HFS+,
> but it is
Bob Friesenhahn wrote:
> I have heard quite a few times that TRIM is "good" for SSD drives but
> I don't see much actual use for it. Every responsible SSD drive
> maintains a reserve of unused space (20-50%) since it is needed for
> wear leveling and to repair failing spots. This means that
[I TRIMmed the thread a bit ;-)]
On Dec 31, 2009, at 1:43 AM, Ragnar Sundblad wrote:
On 31 dec 2009, at 06.01, Richard Elling wrote:
In a world with copy-on-write and without snapshots, it is obvious
that
there will be a lot of blocks running around that are no longer in
use.
Snapshots (a
On Dec 31, 2009, at 1:43 AM, Andras Spitzer wrote:
Let me sum up my thoughts in this topic.
To Richard [relling] : I agree with you this topic is even more
confusing if we are not careful enough to specify exactly what we
are talking about. Thin provision can be done on multiple layers,
a
On 31 dec 2009, at 17.18, Bob Friesenhahn wrote:
> On Thu, 31 Dec 2009, Ragnar Sundblad wrote:
>>
>> Also, currently, when the SSDs for some very strange reason is
>> constructed from flash chips designed for firmware and slowly
>> changing configuration data and can only erase in very large chu
Just an update :
Finally I found some technical details about this Thin Reclamation API :
(http://blogs.hds.com/claus/2009/12/i-love-it-when-a-plan-comes-together.html)
"This week, (December 7th), Symantec announced their “completing the thin
provisioning ecosystem” that includes the necessary
On Thu, 31 Dec 2009, Ragnar Sundblad wrote:
Also, currently, when the SSDs for some very strange reason is
constructed from flash chips designed for firmware and slowly
changing configuration data and can only erase in very large chunks,
TRIMing is good for the housekeeping in the SSD drive. A t
On 31 dec 2009, at 10.43, Andras Spitzer wrote:
> Then came Veritas with this brilliant idea of building a bridge between the
> FS and the SAN frame (this became the Thin Reclamation API), so they can
> communicate which blocks are not in use indeed.
This is exactly what TRIM is for, but could
On 31 dec 2009, at 00.31, Bob Friesenhahn wrote:
> On Wed, 30 Dec 2009, Mike Gerdts wrote:
>>
>> Should the block size be a tunable so that page size of SSD (typically
>> 4K, right?) and upcoming hard disks that sport a sector size > 512
>> bytes?
>
> Enterprise SSDs are still in their infancy.
On 31 dec 2009, at 06.01, Richard Elling wrote:
>
> On Dec 30, 2009, at 2:24 PM, Ragnar Sundblad wrote:
>
>>
>> On 30 dec 2009, at 22.45, Richard Elling wrote:
>>
>>> On Dec 30, 2009, at 12:25 PM, Andras Spitzer wrote:
>>>
Richard,
That's an interesting question, if it's wort
Let me sum up my thoughts in this topic.
To Richard [relling] : I agree with you this topic is even more confusing if we
are not careful enough to specify exactly what we are talking about. Thin
provision can be done on multiple layers, and though you said you like it to be
closer to the app th
On Dec 30, 2009, at 2:24 PM, Ragnar Sundblad wrote:
On 30 dec 2009, at 22.45, Richard Elling wrote:
On Dec 30, 2009, at 12:25 PM, Andras Spitzer wrote:
Richard,
That's an interesting question, if it's worth it or not. I guess
the question is always who are the targets for ZFS (I assume
On Wed, 30 Dec 2009, Mike Gerdts wrote:
Should the block size be a tunable so that page size of SSD (typically
4K, right?) and upcoming hard disks that sport a sector size > 512
bytes?
Enterprise SSDs are still in their infancy. The actual page size of
an SSD could be almost anything. Due t
On 30 dec 2009, at 22.45, Richard Elling wrote:
> On Dec 30, 2009, at 12:25 PM, Andras Spitzer wrote:
>
>> Richard,
>>
>> That's an interesting question, if it's worth it or not. I guess the
>> question is always who are the targets for ZFS (I assume everyone, though in
>> reality priorities
On Wed, Dec 30, 2009 at 3:12 PM, Richard Elling
wrote:
> If the allocator can change, what sorts of policies should be
> implemented? Examples include:
> + should the allocator stick with best-fit and encourage more
> gangs when the vdev is virtual?
> + should the allocato
On Dec 30, 2009, at 12:25 PM, Andras Spitzer wrote:
Richard,
That's an interesting question, if it's worth it or not. I guess the
question is always who are the targets for ZFS (I assume everyone,
though in reality priorities has to set up as the developer
resources are limited). For a ho
Ack..
I've just re-read your original post. :-) It's clear you are talking
about support for thin devices behind the pool, not features inside the
pool itself.
Mea culpa.
So I guess we wait for trim to be fully supported.. :-)
T.
On 31/12/2009 8:09 AM, Tristan Ball wrote:
To some exten
now this is getting interesting :-)...
On Dec 30, 2009, at 12:13 PM, Mike Gerdts wrote:
On Wed, Dec 30, 2009 at 1:40 PM, Richard Elling
wrote:
On Dec 30, 2009, at 10:53 AM, Andras Spitzer wrote:
Devzero,
Unfortunately that was my assumption as well. I don't have source
level
knowledge of
To some extent it already does.
If what you're talking about is filesystems/datasets, then all
filesystems within a pool share the same free space, which is
functionally very similar to each filesystem within the pool being
thin-provisioned. To get a "thick" filesystem, you'd need to set at
l
Richard,
That's an interesting question, if it's worth it or not. I guess the question
is always who are the targets for ZFS (I assume everyone, though in reality
priorities has to set up as the developer resources are limited). For a home
office, no doubt thin provisioning is not much of a use
On Wed, Dec 30, 2009 at 1:40 PM, Richard Elling
wrote:
> On Dec 30, 2009, at 10:53 AM, Andras Spitzer wrote:
>
>> Devzero,
>>
>> Unfortunately that was my assumption as well. I don't have source level
>> knowledge of ZFS, though based on what I know it wouldn't be an easy way to
>> do it. I'm not
On 12/30/2009 2:40 PM, Richard Elling wrote:
There are a few minor bumps in the road. The ATA PASSTHROUGH
command, which allows TRIM to pass through the SATA drivers, was
just integrated into b130. This will be more important to small servers
than SANs, but the point is that all parts of the sof
On Dec 30, 2009, at 10:53 AM, Andras Spitzer wrote:
Devzero,
Unfortunately that was my assumption as well. I don't have source
level knowledge of ZFS, though based on what I know it wouldn't be
an easy way to do it. I'm not even sure it's only a technical
question, but a design question,
> making transactional,logging filesystems
> thin-provisioning aware should be hard to do, as
> every new and every changed block is written to a new
> location. so what applies to zfs, should also apply to btrfs or
> nilfs or similar filesystems.
>
> i`m not sure if there is a good way to make z
On Wed, Dec 30, 2009 at 19:23, roland wrote:
> making transactional,logging filesystems thin-provisioning aware should be
> hard to do, as every new and every changed block is written to a new location.
> so what applies to zfs, should also apply to btrfs or nilfs or similar
> filesystems.
If t
Devzero,
Unfortunately that was my assumption as well. I don't have source level
knowledge of ZFS, though based on what I know it wouldn't be an easy way to do
it. I'm not even sure it's only a technical question, but a design question,
which would make it even less feasible.
Apart from the te
making transactional,logging filesystems thin-provisioning aware should be hard
to do, as every new and every changed block is written to a new location.
so what applies to zfs, should also apply to btrfs or nilfs or similar
filesystems.
i`m not sure if there is a good way to make zfs thin-prov
Hi,
Does anyone heard about having any plans to support thin devices by ZFS? I'm
talking about the thin device feature by SAN frames (EMC, HDS) which provides
more efficient space utilization. The concept is similar to ZFS with the pool
and datasets, though the pool in this case is in the SAN f
68 matches
Mail list logo
