Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: file-backed cgd backup question
mlelstv%serpens.de@localhost (Michael van Elst) writes:
> gdt%lexort.com@localhost (Greg Troxel) writes:
>
>>I dimly knew this, but keep forgetting. Reading vndconfig(8), it does
>>not explain that the normal path leads to incorrect behavior (stale
>>reads from file cache even after closing the vnd, mtime).
>
> vnd opens the backing file when the unit is created and closes
> the backing file when the unit is destroyed. Then you can access
> the file again.
Is there a guarantee of cache consistency for writes before and reads
after?
> The data is written directly to the allocated blocks of the file.
> So exclusively opening the backing file _or_ the vnd unit should
> also be safe. But that's not much different from accessing any file
> concurrently, which also leads to "corrupt", inconsistent backups.
That's a different kind of corrupt, which is that one is reading the
blocks that were written, but perhaps they are not consistent with each
other. Here, it seems someone can read bits from the fs cache that were
a state that existed before vnconfig/write/vnconfig-u.
> Updating the backing file mtime on close sounds useful. I'm not sure
> what effect updating atime/mtime on every access would have.
Agreed.
>> This
>>optimization is sufficiently dangerous and not expected that it needs to
>>be documented clearly and loudly. I just added a note to the man page.
>
> I think the reference to "ciphertext" should be adjusted and the
> text should be toned more neutral when describing the functionality.
I dropped ciphertext; this isn't cgd.
I'm not sure what you mean by neutral. The statement "this makes a file
available as a block device" implies that at least after vnconfig -u,
reading from the file will return the last write while it was
configured. That's a minus, and the speed is a plus.
Maybe you mean that it should tout the speed advantage more?
> Pointing to the -i option to disable the optimization unconditionally
> might also be helpful.
Good point; done.
Home |
Main Index |
Thread Index |
Old Index