On 01/16/15 03:47 PM, Gary Gendel wrote:
On 01/16/2015 10:22 AM, Andrew Gabriel wrote:
On 01/16/15 02:37 PM, Gary Gendel wrote:
# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH
ALTROOT
rpool 68G 49.5G 18.5G - 50% 72% 1.00x ONLINE -
users 928G 72.4G 856G - 1% 7% 1.00x ONLINE -
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 48.9G 16.9G 82K /rpool
rpool/ROOT 44.9G 16.9G 22K legacy
rpool/ROOT/hipster-17 44.9G 16.9G 34.9G /
rpool/dump 1.97G 16.9G 1.97G -
rpool/export 32K 16.9G 32K /export
rpool/swap 2.01G 16.9G 2.01G -
users 72.4G 827G 72.3G /export/home
How does one defragment this?
I presume you are referring to rpool, and not users?
What makes you think you need to?
What do you use the root filesystem for?
I thought about creating a new BE and then sending the current BE to
it, but there doesn't seem to be enough room.
Since rpool can only be either a single disk or a mirror, the easiest
way to defrag it is to attach another mirror side and let it
resilver. The new mirror side will be defragged. Make sure the new
disk is bootable (has grub etc on it), and then zpool split off the
old disk. It would be a good opportunity to move to a bigger rpool
disk too.
Yes, this is the rpool and is mirrored. Would resilvering really
defragment it?
Yes, space is allocated afresh when resilvering (which is a significant
difference from traditional RAID).
I figured that with this high a fragmentation there would be some
penalty in memory consumption and possible disk access.
The FRAG figure there is a measure of free space fragmentation in the
form of how many metaslabs have no blocks of space bigger than 8Mbyte
free, and also takes into account how small their biggest free block is.
50% FRAG can mean something between the following two extremes:
1. half the metaslabs being completely fragmented (no blocks bigger
than 1kbyte available) and half the metaslabs having 16Mbyte blocks, or
2. all the metaslabs having 128Kbyte free blocks available.
I wouldn't worry about 50% on an rpool, although I haven't done any
detailed performance metrics since the metaslab histograms appeared.
Specifically, FRAG does not tell you anything about how fragmented the
layout of your existing data is on the disk, only how easily zfs can
find free space for you to write new data into.
The rpool has gotten worse slowly. This started with somewhere around
OpenSolaris SNV_124 when the disk requirements were much smaller and
has gone though 100s of updates since then.
I'm hanging on to this SunFire v20z until I can figure out a cheap,
less power hungry replacement. It replaced my Sparc SunFire 150 that
started running OpenSolaris around SNV_62! In my SOHO, the V20z runs
the network:
* Firewall and router WAN to LAN.
*** It would be nice to get a DHCPv6 PD client working so I don't have
to have a 4-6 tunnel.
* Web server (Web pages, Wiki, Owncloud, etc.)
* File server (user pool and archive pool).
* Archive server.
* Mail server
* DCHP 4 and 6 server.
* Software testing platform.
Most of the time this machine is lightly loaded. Only when software
testing goes on does it ever sweat. It's kind of a kludge setup as I
have the disks off of sata cables directly from the controller to the
disks in an external cabinet because of the lack of sata multiplexing.
That's much better than trying to use SATA drives via port expanders!
--
Andrew
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
