On 30.06.09 22:27, Ricardo M. Correia wrote:
> On Ter, 2009-06-30 at 10:58 -0700, Jeremy Archer wrote:
>> OK..
>>
>>> Once the file is deleted, ARC entry {dva 5 txg 5} is no longer valid.
>>> So why do we need it?
>>>> Let's suppose file is removed from the directory but is still open by
>>>> some process...
>
> I think both of you (Jeremy and Victor) are getting a bit confused (or
> maybe it's me?).
Agree, my example was not good for the proposed scenario. Need to think
more before typing. May be it is just time to go home...
>
> Even if file A is removed from the directory but is still open, this
> wouldn't cause a block of File B from getting assigned the same DVA as a
> block from the (unlinked from the directory, but still existent on-disk)
> file A, as in the example provided.
>
> The blocks of the unlinked file A would only be freed when the file is
> closed by the process (assuming no snapshot is present), at which point
> there's no need to access its cached blocks anymore.
>
> If a snapshot is taken after file A is written but before it is
> unlinked, then the blocks of file B would never be assigned the same
> DVAs as the blocks of file A, since the blocks of file A would only be
> freed after the snapshot is deleted.
>
>> On a traditional fle system, you would not be able to delete an open file.
>> Which I believe is good.
>
> Actually, I think you can do that on most UNIX filesystems.
>
>> So, on ZFS you say, you can write to a file that you opened in txg 5
>> that was already deleted in txg 10?
>
> If by deleted you mean unlinked from the directory but still open by a
> process, then yes (as in most UNIX filesystems).
>
>> When txg 5 completes, you will have the updated content, and when txg 10
>> finishes, you will have a deleted file.
>
> The file will still be there in txg 10, but linked to a special ZAP,
> hidden from the namespace.
>
> As to why the ARC can cache two blocks with the same DVA allocated in
> different txgs (which means one of them would be invalid?), that I don't
> know..
>
> Cheers,
> Ricardo
>
>
> _______________________________________________
> zfs-code mailing list
> zfs-code at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-code
