> Peter Tribble wrote: > > On 4/24/07, Darren J Moffat <[EMAIL PROTECTED]> > wrote: > >> With reference to Lori's blog posting[1] I'd like > to throw out a few of > >> my thoughts on spliting up the namespace. > > > > Just a plea with my sysadmin hat on - please don't > go overboard > > and make new filesystems just because we can. Each > extra > > filesystem generates more work for the > administrator, if only > > for the effort to parse df output (which is more > than cluttered enough > > already). > My first reaction to that, is yes, of course, extra > file systems are extra > work. Don't require them, and don't even make them > the default unless > they buy you a lot. But then I thought, no, let's > challenge that a bit. > > Why do administrators do 'df' commands? It's to find > out how much space > is used or available in a single file system. That > made sense when file > systems each had their own dedicated slice, but now > it doesn't make that > much sense anymore. Unless you've assigned a quota > to a zfs file system, > "space available" is meaningful more at the pool > level. And if you DID > assign a quota to the file system, then you really > did want that part of > the name space to be a separate, and separately > manageable, file system.
I'd like to put my sysadmin hat on and add to this: Yes, if you start adding quota's, etc. you'll have to start looking at doing df's again but this is actually easier with zfs (zfs list). Now I can see, very easily, where my space is being allocated and start diving in from there instead of the multiple du -ks * |sort -n recursive rampages I do on one big filesystem. Also, if I start using zfs and some of the other features (read only) for example, I can start taking and locking down some of these filesystems (/usr perhaps???) so I no longer need to worry about the space being allocated in /usr. Or setting reserve and quota's on file systems, basically eliminating them from my constant monitoring and free space shuffle of where did my space go. > > With zfs, file systems are in many ways more like > directories than what > we used to call file systems. They draw from pooled > storage. They > have low overhead and are easy to create and destroy. > File systems > re sort of like super-functional directories, with > quality-of-service > control and cloning and snapshots. Many of the > things that sysadmins > used to have to do with file systems just aren't > necessary or even > meaningful anymore. And so maybe the additional work > of managing > more file systems is actually a lot smaller than you > might initially think. I believe so. Just having zfs boot on my system for a couple of days and breaking out the major food groups, I can easily see where my space is at - again zfs list is much faster than du -ks and I don't have to be root for it to be 100% accurate - my postgres data files aren't owned by me;) Other things (I've mentioned to Lori off alias) is the possible ability to compress some file systems - again possibly /usr and /opt??? Breaking out the namespace provides the flexibility of separate file systems and snapping/cloning/administrating those as needed with the benefits of a single root file system - one disk and not having to get the partition space right. But, there is the matter of balance - too much would be overkill. Perhaps the split and merge RFE's would bridge that gap to provide again more flexibility? > > In other words, think about ALL of the implications > of using zfs, > not just some. > > We've come up with a lot of good reasons for having > multiple > file systems. So we know that there are benefits. > We also know > hat there are costs. But if we can figure out a way > to keep the > costs low, the benefits might outweigh them. > > > > > In other words, let people have a system with just > one filesystem. > I think I can agree with this, but I'm not absolutely > certain. On the > one hand, sure, more freedom is better. But I'm > concerned that > our long-term install and upgrade strategies might be > constrained > by having to support configurations that haven't been > set up with > the granularity needed for some kinds of valuable > storage management > features. > > This conversation is great! I'm getting lots of good > information > and I *really* want to figure out what's best, even > if it challenges > some of my cherished notions. > > Lori > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discu > ss > This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
