Jasse Jansson wrote: <snip> > > While you're at it, why don't make two kinds of snapshots. > > 1. A user initiated snapshot, usnap, that the user controls and counts > towards the quota limit.
These already exist? They are called backups ... rsync, cpdup, cp, bacula, amanda, etc. already do this and as the source you can provide them with any snapshot that you have access to or even the current dataset if you don't care if it's changing while you're copying it. It might be nice from certain perspectives (though, I'd disagree) but in any case, this is off-topic, we were supposed to be discussing user/pfs quotas with current HAMMER fs and in this case, even though the user only has indirect control over snapshots (asking the admin to manage them and by limiting rewrites of files), quotas are supposed to limit the user's impact on disk space ... if historical data is not accounted for, there is in fact no limit on the user's impact on disk space (e.g. you give the user a hard quota of 1GB ... the user will take a 1TB file, split it into 1GB sized parts and start saving it over and over itself ... the user will still be able to access most/all those parts from file's history, but will only pay the price of the last piece or in an even worse scenario, will fill up your drive and the other nicer users wont be able to use your services). And like I said before ... the users home dir can be nohistory and the user won't have to worry about his snapshots taking space up. If the user wants transparent history and snapshots which are made automatically in the bg, then the user has to pay the price. If the user doesn't care about that, then his dir can be nohistory and then the quota system can only count the current dataset, since there is no historical data for that user. -- Please do not CC me, since I already receive everything from these MLs. Regards, Rumko
