> On Sat, 7 Jun 2008, Mattias Pantzare wrote: > > > > If I need to count useage I can use du. But if you > can implement space > > usage info on a per-uid basis you are not far from > quota per uid... > > That sounds like quite a challenge. UIDs are just > numbers and new > ones can appear at any time. Files with existing > UIDs can have their > UIDs switched from one to another at any time. The > space used per UID > needs to be tallied continuously and needs to track > every change, > including real-time file growth and truncation. We > are ultimately > talking about 128 bit counters here. Instead of > having one counter > per filesystem we now have potentially hundreds of > thousands, which > represents substantial memory.
But if you already have the ZAP code, you ought to be able to do quick lookups of arbitrary byte sequences, right? Just assume that a value not stored is zero (or infinity, or uninitialized, as applicable), and you have the same functionality as the sparse quota file on ufs, without the problems. Besides, uid/gid/sid quotas would usually make more sense at the zpool level than at the individual filesystem level, so perhaps it's not _that_ bad. Which is to say, you want user X to have an n GB quota over the whole zpool, and you probably don't so much care whether the filesystem within the zpool corresponds to his home directory or to some shared directory. > Multicore systems have the additional challenge that > this complex > information needs to be effectively shared between > cores. Imagine if > you have 512 CPU cores, all of which are running some > of the ZFS code > and have their own caches which become invalidated > whenever one of > those counters is updated. This sounds like a no-go > for an almost > infinite-sized pooled "last word" filesystem like > ZFS. > > ZFS is already quite lazy at evaluating space > consumption. With ZFS, > 'du' does not always reflect true usage since updates > are delayed. Whatever mechanism can check at block allocation/deallocation time to keep track of per-filesystem space (vs a filesystem quota, if there is one) could surely also do something similar against per-uid/gid/sid quotas. I suspect a lot of existing functions and data structures could be reused or adapted for most of it. Just one more piece of metadata to update, right? Not as if ufs quotas had zero runtime penalty if enabled. And you only need counters and quotas in-core for identifiers applicable to in-core znodes, not for every identifier used on the zpool. Maybe I'm off base on the details. But in any event, I expect that it's entirely possible to make it happen, scalably. Just a question of whether it's worth the cost of designing, coding, testing, documenting. I suspect there may be enough scenarios for sites with really high numbers of accounts (particularly universities, which are not only customers in their own right, but a chance for future mindshare) that it might be worthwhile, but I don't know that to be the case. IMO, even if no one sort of site using existing deployment architectures would justify it, given the future blurring of server, SAN, and NAS (think recent SSD announcement + COMSTAR + iSCSI initiator + separate device for zfs zil & cache + in-kernel CIFS + enterprise authentication with Windows interoperability + Thumper + ...), the ability to manage all that storage in all sorts of as-yet unforseen deployment configurations _by user or other identity_ may well be important across a broad base of customers. Maybe identity-based, as well as filesystem-based quotas, should be part of that. This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
