For various reasons including regulatory compliance, I would like to have a Write Once, Read Many (WORM) storage partition and wanted to know if ZFS can enable this.
(at least some of) the metadata are kept on separate writable media.
If a file needs to be modified, a new record is written to WORM, and the metadata get manipulated to point to the new record, but the original user data also persist on WORM storage.
Whether "overwritten" user data can be accessed (e.g. by file versioning) depends on the implementation.
I have no idea if ZFS might be adapted for WORM (but there are some hooks like "special" pools for separate storage of metadata that might assist).
ZFS has a complicated on-disk format, Even if you hack it up to never overwrite occupied blocks on the media - how do you access the old data? That is highly non-trivial.
I’m not sure whether the file system is the right entity to administer this. Just like choosing the “best” programming language depends on the task, you choose a file system suitable for your goal. I dare say ZFS is particularly unsuitable for this task. You could of course
Bash:
chflags uunlink,uappend filename # or sunlink,sappend if you have root privileges
after each file’s creation, yet this requires manual intervention (there is no mechanism analogous to umask(2)) and there is no flag forbiddingchflags(2) (i. e. the effects are reversible [except sunlink and sappend in kern.securelevel greater than zero]).
[sub]PS: The capsicum(4) facility could deprive writing processes of the truncate/seek/unlink capabilities, but this is enforced by the kernel, not the file system.[/sub]
For various reasons including regulatory compliance, I would like to have a Write Once, Read Many (WORM) storage partition and wanted to know if ZFS can enable this.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
