On Dec 30, 2009, at 12:41 PM, Tomas Ögren wrote:
On 30 December, 2009 - Dennis Yurichev sent me these 0,7K bytes:
Hi.
Why each file can't have also "expiration date/time" field, e.g.,
date/time when operation system will delete it automatically?
This could be usable for backups, camera raw files, internet browser
cached files, etc.
Using extended attributes + cron, you could provide the same service
yourself and other similar (or not) things people would like to do
without developers providing it for you in the fs..
I recall a long discussion about this sort of feature on usenet back in
the late '80s. The problem is that deletion is not a good result. For
example, suppose you run a server for a year with a year expiry
policy. Will it be able to reboot? Some files are only accessed at
boot time, so how will you know what files are good candidates?
If you know the files that are good candidates, then why not go
ahead and deal with them directly?
s/reboot/login/g
IIRC, the consensus was that file age or last access time is not
suitable for a deletion policy. However, it may be useful in a
HSM system. I have limited experience with HSM systems in
a large, multiuser environment, but I would not be happy to
have the system go to tape to retrieve my .profile when I login.
Which reminds me... whatever happened to the ADM project?
http://hub.opensolaris.org/bin/view/Project+adm/
looks neglected to me...
I won't even begin to talk about snapshots... when you access
a file in the snapshot, the file attributes are not changed, because
the snapshot is read only. Dang it, I said I wouldn't go there...
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
