[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 (and their clones) changes that use case. So in a world of
snapshots, there will be fewer blocks which are not used. Remember,
the TRIM command is very important to OSes like Windows or OSX
which do not have file systems that are copy-on-write or have decent
snapshots. OTOH, ZFS does copy-on-write and lots of ZFS folks use
snapshots.
I don't believe that there is such a big difference between those
cases.
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 those markets which are driving TRIM adoption.
[TRIMmed]
Once a block is freed in ZFS, it no longer needs it. So the "problem"
of TRIM in ZFS is not related to the recent txg commit history.
It may be that you want to save a few txgs back, so if you get
a failure where parts of the last txg gets lost, you will still be
able to get an old (few seconds/minutes) version of your data back.
This is already implemented. Blocks freed in the past few txgs are
not returned to the freelist immediately. This was needed to enable
uberblock recovery in b128. So TRIMming from the freelist is safe.
This could happen if the sync commands aren't correctly implemented
all the way (as we have seen some stories about on this list).
Maybe someone disabled syncing somewhere to improve performance.
It could also happen if a "non volatile" caching device, such as
a storage controller, breaks in some bad way. Or maybe you just
had a bad/old battery/supercap in a device that implements
NV storage with batteries/supercaps.
The
issue is that traversing the free block list has to be protected by
locks, so that the file system does not allocate a block when it is
also TRIMming the block. Not so difficult, as long as the TRIM
occurs relatively quickly.
I think that any TRIM implementation should be an administration
command, like scrub. It probably doesn't make sense to have it
running all of the time. But on occasion, it might make sense.
I am not sure why it shouldn't run at all times, except for the
fact that it seems to be badly implemented in some SATA devices
with high latencies, so that it will interrupt any data streaming
to/from the disks.
I don't see how it would not have negative performance impacts.
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
