[OpenIndiana-discuss] rpool defragmentation

Andrew Gabriel illumos at cucumber.demon.co.uk
Fri Jan 16 17:47:11 UTC 2015


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



More information about the openindiana-discuss mailing list