> 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. > > 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). > > 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.
Our problem isn't "we don't have enough storage space". Our problem is that the snapshots reduce the filesystem space available to users. Simply creating the snapshot begins squeezing them out of their own space. Just billing people for it doesn't solve the problem. Simply giving people more space doesn't solve the problem, either. I did think of another option -- allow filesystems to dynamically grow their quotas themselves by the size of the snapshots. This might be easiest to implement -- just add a toggle in the zfs set/get parameters. If it's integrated into the filesystem itself, keeping up with the changing size of the data should be a non-issue. Actually, I guess that's fairly similar to the separate quota for snapshot data idea. BP -- [EMAIL PROTECTED] _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
