On Sat, 2005-12-03 at 05:20, Eric Schrock wrote:> On Fri, Dec 02, 2005 at 10:59:05PM +0000, Peter Tribble wrote:
> >
> > The really bad thing about this is that as users have no control over
> > the snapshots, they really have no control over their space used.
>
> What about a world where we have delegated administration, and the user
> is allowed to take snapshots? Shouldn''t that be counted against
them?
> Or even better, what about per-zone delegation available today?
Well, the simplest way would be to charge the "owner" of the snapshot
(where owner is the person who initiated the snapshot) with the space
used.
[Presumably delegation carries with it some notion of ownership.]
So, if I''m delegated a filesystem with a 1G quota, and I take a
snapshot, then
the space used by the snapshot gets charged to me. If some higher-level
admin
decides to take a snapshot of my data for their purposes, then they
should get
charged.
> What if you _want_ to limit the amount of space consumed by snapshots?
> You can''t have a separate ''snapshot quota'', or
else you''ll get equally
> weird behavior and the whole thing is rather pointless.
>
> > This doesn''t seem right. I''m not sure about
reservations, but my
> > recollection of snapshots on netapp was that they didn''t
count against
> > my quota.
>
> So where should snapshots be accounted for? At the pool level? What if
> the datasets are exported to a zone, where the zone administrator can
> take arbitrary number of snapshots?
The pool level doesn''t seem right, for sure.
But if I export a dataset to a zone (and this gets much cleaner it you
can
export a container rather than just a filesystem), then I should be able
to limit
the zone administrator''s use of that overall dataset, including any
snapshots.
But my expectation would be that any snapshots they made would be
charged against
their overall allocation, not against individual filesystems.
> Even if we could account for the above situations, we now have an
> entirely new problem where a user can choose to re-write all the data in
> a filesystem and arbitrarily run _other_ datasets out of space. We now
> have a security problem in addition to everything else.
But it''s not the user who''s causing the problem. It''s
whoever is taking
all those snapshots who is causing the problem.
> Do you have any suggestions to how to fix this?
Well, generally, charge to the administrator rather than the filesystem.
Not
having a full understanding of how the notion of ownership might apply
to
a zfs dataset, I''m not sure I can be more specific. (In the simplest
case, this
would mean that all snapshots get charged against the pool or top-level
filesystem,
if there is one.)
However, we might step back a bit and clarify exactly what the intention
of quotas
and reservations is. The current implementation has a quota applying to
a filesystem
and its descendants. Now, I''m clear that creating another filesystem
under an existing
filesystem leads to a descendant. However, I see snapshots and clones as
siblings
rather than descendants. If that''s the case, then creating a container
above the
target filesystem and applying the quota to that would allow you to
limit the
overall usage, while also allowing you to limit usage of the filesystem
itself.
--
-Peter Tribble
L.I.S., University of Hertfordshire - http://www.herts.ac.uk/
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/