[zfs-discuss] Re: TRIM support?
ryao at cs.stonybrook.edu
Sat Mar 3 00:09:36 EST 2012
On Fri, Mar 2, 2012 at 11:47 PM, Christ Schlacta <aarcane at aarcane.org> wrote:
> On 3/2/2012 20:45, Richard Yao wrote:
>> On Fri, Mar 2, 2012 at 11:21 PM, Christ Schlacta<aarcane at aarcane.org> wrote:
>>> On 3/2/2012 19:47, Manuel Amador wrote:
>>>> Are you sure?
>>>> On Friday, March 02, 2012 14:38:01 Uncle Stoatwarbler wrote:
>>>>> On 02/03/12 12:48, Manuel Amador wrote:
>>>>>> It is a bad idea to persist the L2ARC because the data files on the ZFS
>>>>>> pool could change without the L2ARC present.
>>>>> In this case the cache would be invalidated anyway.
>>>>> This did get some discussion about 6-12 months ago.
>>>> Reference please.
>>> Isn't there a transactionID of some sort that identifies the last
>>> change, and isn't that present in the cache AND on disk? If it's
>>> suddenly different on import, then we trim across the disk and
>>> reinitialize the cache ? Just speculation and suggestion. Ignore if
>> That is my expection, although it needs to be checked. There is the
>> danger of importing a pool from another implementation that did
>> something strange, so it is not only a matter of it being safe when
>> looking at the ZFSOnLinux code.
> Perhaps better to trim to be on the safe side when we're unsure, but
> there should be some simple way to be sure. Is there a "reserved" area
> in the header we can reserve a bit in?
The problem with a reserved area is that another project could decide
to use it to do something else or to do the same thing in an
incompatible way. If this is done, it probably should involve Illumos
so that there is some sane way of coordinating that. I understand that
they intend to implement feature bits that might help here.
More information about the zfs-discuss