1) Say I have a mirrored ZFS file system on two identical 73GB disks e.g. same manufacturer. Now say I replace one of these disks (cuz it breaks) with another vendor''s 73GB disk but this disk just happens to be a little smaller ( like this would EVERY happen ... ;D ). I think ZFS should fail to mirror the file system but I''m looking for something more specific then just my own assumptions. 2) ZFS Snapshot "capping" - I got this question recently. Is there a way to cap how big a snapshot can be ? I *think* the answer to this is related to quotas. Say for instance home directory of a user that''s treated as a file system - snapshots live under .zfs and .zfs is technically in that file systems quota space - so /sorta/. But I think the question is more related to can ZFS snapshots have their own space restrictions outside of quotas. Maybe some folks might want to say "I want 100GB for this file system and of this I want to give snapshots 10GB and not more." or maybe even "100GB to the file system and 10GB to it snapshots - exclusive of each other." Is this possible ? Thanks for your time :) This message posted from opensolaris.org
Sean O''Neill wrote:> 1) Say I have a mirrored ZFS file system on two identical 73GB disks e.g. > same manufacturer. Now say I replace one of these disks (cuz it breaks) > with another vendor''s 73GB disk but this disk just happens to be a little > smaller ( like this would EVERY happen ... ;D ). I think ZFS should fail > to mirror the file system but I''m looking for something more specific then > just my own assumptions.IMHO, "failing" under such circumstances is undesirable. Further, it reeks of disk-based RAID (lacking context) limitations. As long as there is free space, why should we want this limitation? -- richard
On 2005-12-05 20:52, Sean O''Neill wrote:> 1) Say I have a mirrored ZFS file system on two identical 73GB disks > e.g. same manufacturer. Now say I replace one of these disks (cuz it > breaks) with another vendor''s 73GB disk but this disk just happens to > be a little smaller ( like this would EVERY happen ... ;D ). I think > ZFS should fail to mirror the file system but I''m looking for > something more specific then just my own assumptions.Assuming that there is still some space left on the disk remaining in the mirror it would be better to shrink the filesystem to fit into the new, slightly smaller, disk. Thus the origional disk would instead be considered a little to large instead. However, I don''t know how ZFS would do in this situation, but what I''ve seen of it so far suggests that it should be able to handle this.> 2) ZFS Snapshot "capping" - I got this question recently. Is there a > way to cap how big a snapshot can be ? I *think* the answer to this > is related to quotas. Say for instance home directory of a user > that''s treated as a file system - snapshots live under .zfs and .zfs > is technically in that file systems quota space - so /sorta/. But I > think the question is more related to can ZFS snapshots have their > own space restrictions outside of quotas. Maybe some folks might > want to say "I want 100GB for this file system and of this I want to > give snapshots 10GB and not more." or maybe even "100GB to the file > system and 10GB to it snapshots - exclusive of each other." Is this > possible ?As you say the snapshots'' space count towards the quota of the filesystem and you can not use the ZFS quota-function to limit the size of the snapshots. I do not think that you can have the snapshots on another FS (not sure). What you could do (again, not sure) is to use some other quota-system to limit the size of the .zfs-directory and thereby limit the size of the snapshots. Anyone who knows better please correct me. Erik Wikstr?m -- "I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone" -- Bjarne Stroustrup
On 12/5/05, Sean O''Neill <sean.w.oneill at sun.com> wrote:> 1) Say I have a mirrored ZFS file system on two identical 73GB disks e.g. same manufacturer. Now say I replace one of these disks (cuz it breaks) with another vendor''s 73GB disk but this disk just happens to be a little smaller ( like this would EVERY happen ... ;D ). I think ZFS should fail to mirror the file system but I''m looking for something more specific then just my own assumptions. > > 2) ZFS Snapshot "capping" - I got this question recently. Is there a way to cap how big a snapshot can be ? I *think* the answer to this is related to quotas. Say for instance home directory of a user that''s treated as a file system - snapshots live under .zfs and .zfs is technically in that file systems quota space - so /sorta/. But I think the question is more related to can ZFS snapshots have their own space restrictions outside of quotas. Maybe some folks might want to say "I want 100GB for this file system and of this I want to give snapshots 10GB and not more." or maybe even "100GB to the file system and 10GB to it snapshots - exclusive of each other." Is this possible ? >from my understanding, snapshots work like this say you have 100 1GB files on a file system. when you take a snapshot. it freezes a copy of the files. the act of taking a snapshot uses close to 0 bytes of data. But if you later remove 1 or more of the files that are in the snapshot, they aren''t physically removed from the filesystem. So if you had 1GB left of space, before the snapshot, and you removed a file. You gain no storage because the snapshot holds all the files as is, but the current filesystem doesn''t show the files you deleted. Of course ZFS doesn''t work on files level but on the block level, so its a bit more complex. But that should get you an idea of what is happening. James Dickens uadmin.blogspot.com> Thanks for your time :) > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
Sean O''Neill wrote:> 2) ZFS Snapshot "capping" - I got this question recently. Is there a > way to cap how big a snapshot can be ? I *think* the answer to this is > related to quotas. Say for instance home directory of a user that''s > treated as a file system - snapshots live under .zfs and .zfs is > technically in that file systems quota space - so /sorta/. But I think > the question is more related to can ZFS snapshots have their own space > restrictions outside of quotas. Maybe some folks might want to say "I > want 100GB for this file system and of this I want to give snapshots > 10GB and not more." or maybe even "100GB to the file system and 10GB to > it snapshots - exclusive of each other." Is this possible ?In your example of a 100GB dataset quota and a 10GB snapshot quota, say you''ve got 20GB of data on a dataset D and no snapshots. Create a snapshot S, which starts off consuming no space, then remove all the files from D with "rm -r". Do you mean for this to fail when you''ve removed files totalling 10GB, because S would then be consuming its entire 10GB quota through hanging onto data that is no longer accessible from D? This is worse than just counting all the live/reachable data from D and its snapshots against D''s quota. The only way to remove or rewrite any more of the files in D that were snapshotted by S would be to increase S''s quota, or delete the snapshot altogether. If you want a policy where old snapshots are deleted when they are holding onto too much data, you could do it with a cron job pretty easily right now. -Jason
On Mon, Dec 05, 2005 at 07:32:47PM -0800, Sean O''Neill wrote:> > Assuming that there is still some space left on the disk remaining > > in the mirror it would be better to shrink the filesystem to fit > > into the new, slightly smaller, disk. Thus the origional disk would > > instead be considered a little to large instead. However, I don''t > > know how ZFS would do in this situation, but what I''ve seen of it so > > far suggests that it should be able to handle this. > > Thanks for the reply. > > Now that poses an interesting question in and of itself. You have a > failed mirror situation. Can you shrink the one remaining mirror to > accomdate your suggestion ? Seems like a totally feasible thing. > Just looking to see if ZFS would say "Hey Dork, you installed a > slightly smaller disk ... please shrink the remaining mirror by # > amount and we''re in business." or some other rational indicator that > this issue has come up.Actually, this doesn''t work in the current version. We''re working on this class of problems - they all boil down to the device removal problem. That is, taking space ZFS was using and removing it, re-locating any data that was using the soon-to-be-gone space. As you might imagine, there are some tricks involved, most having to do with handling snapshots. You''ll be sure to hear more about this as we finish working out the final solution. Thanks for taking the time to try out ZFS. --Bill
I was asked this question to see what the possibilities are. Failing is probably a strong word to use here but some sort of "indicator of a possible issue" -- how''s that - better ? This message posted from opensolaris.org
> > Assuming that there is still some space left on the > disk remaining in > the mirror it would be better to shrink the > filesystem to fit into the > new, slightly smaller, disk. Thus the origional disk > would instead be > considered a little to large instead. However, I > don''t know how ZFS > would do in this situation, but what I''ve seen of it > so far suggests > that it should be able to handle this.Thanks for the reply. Now that poses an interesting question in and of itself. You have a failed mirror situation. Can you shrink the one remaining mirror to accomdate your suggestion ? Seems like a totally feasible thing. Just looking to see if ZFS would say "Hey Dork, you installed a slightly smaller disk ... please shrink the remaining mirror by # amount and we''re in business." or some other rational indicator that this issue has come up. This message posted from opensolaris.org