> First, ZFS allows one to take advantage of large, inexpensive Serial ATA > disk drives. Paraphrased: "ZFS loves large, cheap SATA disk drives". So > the first part of the solution looks (to me) as simple as adding some > cheap SATA disk drives.
I hope not. We have quotas available for a reason. There are legitimate reasons for putting an administrative upper bound on storage space. It's not always about disk acquisition costs. The ability to have the user own their space and the administrator own the snapshot would look good to me. If the user owns both, I expect them to trade snapshots for space. I would prefer to be able to guarantee snapshots as part of a defined recovery system without limiting access to their quota. > Next, after extra storage space has been added to the pool, it's a simple > matter of accounting to subtract the size of the ZFS snapshots from the > users' disk space to calculate their actual live storage and bill for it! > > Next, periodic snapshots can be made and older snapshots either deleted or > moved to even lower cost storage media (e.g., tape, CDROMs, DVDs etc). I don't care how much bigger you make it. At some point the space will be used. Then the user deletes a subtree and doesn't get any of the space back because of snapshots.... and I don't want the snapshots deleted. > Next - 50Mb quotas!?? You've got to be kidding. Let me check my > calendar; yep - it's 2006. You are kidding ... right? If you're not > kidding, then you've got a business/management issue and not a technical > issue to resolve. So pretend it's 500G. The suggestions still seem very valid to me. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
