On Mon, Oct 20, 2014 at 14:24:23 -0400, Nathan Stratton Treadway wrote:
> If that's indeed the problem, it should be possible (as an alternative
> to rebuilding Amanda [or upgrading to a later version]) to simply shrink
> the size of the ZFS partition down enough to avoid triggering the
> overflow.
> 
> You could just do that by trial and error, or if you send the output of
>   df -v /var/spool/amanda/disk1 /var/spool/amanda/disk2
> and
>   df -g /var/spool/amanda/disk1 /var/spool/amanda/disk2
> , I'll see if I can tell from the 2.5 code what's overflowing and come
> up with the max size that should work...

Chris sent me the output of "df -g /var/spool/amanda/disk2":

/var/spool/amanda/disk2(jpool/amandaspace ):   131072 block size           512 
frag size
419430400 total blocks  167374111 free blocks 167374111 available       
167432983 total   files                                                         
                              
167374111 free files     67174417 filesys id
      zfs fstype       0x00000004 flag             255 filename length

...and that turned out to have the key clue, specifically the section
saying "512 frag size".

It turns out that in the Amanda 2.5.1p3 code line the routine to check
holding disk free space does some calculations that assume the frag size
is a multiple of 1024, and the 512 frag size found here caused it to
round everything down to zero.  (That's why the amcheck message says
"only 0 KB free", rather than some number that results from an integer
overflow situation.)

(The frag size on the UFS filesystem containing his other holding disk
was 1024, so it is indeed a problem specific to ZFS in this case.)


I did a little web searching and it seems that the "ashift" setting on
ZFS vdevs might possibily be related to the frag size value for the
filesystem, but I don't have access to a Solaris system where I can
create a ZFS filesystem using a greater-than-9 ashift and then confirm
that df -g reports a "frag size" bigger than 512.

I believe that if it did so, Amanda 2.5.1p3 would then be able to use
that holding disk -- but on the other hand it seems that any version of
Amanda 2.5.2 or later fixes this particular bug, so it might be easier
just to upgrade Amanda rather than attempting to fix this on the ZFS
side.

                                                        Nathan


p.s. A few related URLs, just to record them somewhere:

The code in question:
  
http://amanda.cvs.sourceforge.net/viewvc/amanda/amanda/server-src/amcheck.c?revision=1.149.2.10&view=markup&pathrev=amanda251p3#l87
  
http://amanda.cvs.sourceforge.net/viewvc/amanda/amanda/common-src/statfs.c?revision=1.16&view=markup&pathrev=amanda251p3#l133
  
A bug covering the same problem in filesystem free space calculations,
though in a different environment:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420100



----------------------------------------------------------------------------
Nathan Stratton Treadway  -  [email protected]  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Reply via email to