> 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
