Bob Friesenhahn wrote:
On Thu, 12 Mar 2009, Jorgen Lundman wrote:
User-land will then have a daemon, whether or not it is one daemon per
file-system or really just one daemon does not matter. This process
will open '/dev/quota' and empty the transaction log entries
constantly. Take the uid,gid entries and update the byte-count in its
database. How we store this database is up to us, but since it is in
user-land it should have more flexibility, and is not as critical to
be fast as it would have to be in kernel.
In order for this to work, ZFS data blocks need to somehow be associated
with a POSIX user ID. To start with, the ZFS POSIX layer is implemented
on top of a non-POSIX Layer which does not need to know about POSIX user
IDs. ZFS also supports snapshots and clones.
Yes, the DMU needs to communicate with the ZPL to determine the uid & gid to
charge each file to. This is done using a callback.
The support for snapshots, clones, and potentially non-POSIX data
storage, results in ZFS data blocks which are owned by multiple users at
the same time, or multiple users over a period of time spanned by
multiple snapshots. If ZFS clones are modified, then files may have
their ownership changed, while the unmodified data continues to be
shared with other users. If a cloned file has its ownership changed,
then it would be quite tedious to figure out which blocks are now
wholely owned by the new user, and which blocks are shared with other
users. By the time the analysis is complete, it will be wrong.
Before ZFS can apply "per-user" quota management, it is necessary to
figure out how individual blocks can be charged to a user. This seems
to be a very complex issue and common usage won't work with your proposal.
Indeed. We have decided to charge for "referenced" space. This is the same
concept used by the "referenced", "refquota", and "refreservation"
properties, and reported by stat(2) in st_blocks, and du(1) on files today.
This makes the issue much simpler. We don't need to worry about blocks being
shared between clones or snapshots, because we charge for every time a block
is referenced. When a clone is created, it starts with the same user
accounting information as its origin snapshot.
--matt
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
