On Sat, 2007-04-28 at 17:48 +0100, Peter Tribble wrote:
On 4/26/07, Lori Alt <[EMAIL PROTECTED]> wrote:
Peter Tribble wrote:
<snip>
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.
True, but it's actually quite hard to get at the moment. It's easy if
you have a single pool - it doesn't matter which line you look at.
But once you have 2 or more pools (and that's the way it would
work, I expect - a boot pool and 1 or more data pools) there's
an awful lot of output you may have to read. This isn't helped
by zpool and zfs giving different answers., with the one from zfs
being the one I want. The point is that every filesystem adds
additional output the administrator has to mentally filter. (For
one thing, you have to map a directory name to a containing
pool.)
It's actually quite easy and easier than the other alternatives (ufs,
veritas, etc):
# zfs list -rH -o name,used,available,refer rootdg
And now it's setup to be parsed by a script (-H) since the output is
tabbed. The -r says to recursively display children of the parent and
the -o with the specified fields says to only display the fields
specified.
(output from one of my systems)
blast(9):> zfs list -rH -o name,used,available,refer rootdg
rootdg 4.39G 44.1G 32K
rootdg/nvx_wos_62 4.38G 44.1G 503M
rootdg/nvx_wos_62/opt 793M 44.1G 793M
rootdg/nvx_wos_62/usr 3.01G 44.1G 3.01G
rootdg/nvx_wos_62/var 113M 44.1G 113M
rootdg/swapvol 16K 44.1G 16K
Even tho the mount point is setup as a legacy mount point, I know where
each of them is mounted due to the vol name.
And yes, this system has more than one pool:
blast(10):> zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
lpool 17.8G 11.4G 6.32G 64% ONLINE -
rootdg 49.2G 4.39G 44.9G 8% ONLINE -
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
are 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.
Oh, I agree. The trouble is that sysadmins still have to work using
their traditional tools, including their brains, which are tooled up
for cases with a much lower filesystem count. What I don't see as
part of this are new tools (or enhancements to existing tools) that
make this easier to handle.
Not sure I agree with this. Many times, you end up dealing with
multiple vxvol's and file systems. Anything over 12 filesystems and
you're in overload (at least for me;) and I used my monitoring and
scripting tools to filter that for me.
Many of the systems I admin'd were setup quite differently based on use
and functionality and disk size.
Most of my tools were setup to take most of these into consideration and
the fact that we ran almost every flavor of UNIX possible using the
features of each OS as appropriate.
Most of the tools will still work with zfs (if using df, etc) but it
actually makes it easier once you have a monitoring issue - running out
of space for example.
Most tools have high and low water marks so when a file system gets too
full, you get a warning. ZFS makes this much easier to admin as you can
see which file system is being the hog and go directly to that file
system and hunt instead of first finding the file system, hence the
debate of the all-in-one / slice or breaking up to the major os fs's.
Benefit of all-in-one / is you didn't have to guess at how much space
you needed for each slice so you could upgrade, add optional software
without needing to grow/shrink the OS.
Drawback, if you filled up the file system, you had to hunt where it was
filling up - /dev, /usr, /var/tmp, /var, / ???
Benefit of multiple slices was one fs didn't affect the others if you
filled it up and you could find which was the problem fs very easily but
if you estimated incorrectly, you had wasted disk space in one slice and
not enough in another.
ZFS gives you the benefit of both all-in-one and partitioned as it draws
from a single pool of storage but also allows you to find which fs is
being the problem and lock it down with quota's and reservations.
For example, backup tools are currently filesystem based.
And this changes the scenario how? I've actually been pondering this
for quite some time now. Why do we backup the root disk? With many of
the tools out now, it makes far more sense to do a flar/incremental
flars of the systems and or create custom jumpstart profiles to rebuild
the system.
