xfs
[Top] [All Lists]

free space of root partition decreases unaccountably by some 1024 blocks

To: SGI Project XFS mailing list <xfs@xxxxxxxxxxx>
Subject: free space of root partition decreases unaccountably by some 1024 blocks on every umount+linux shutdown
From: Roland Eggner <edvx1@xxxxxxxxxxxxxxxxxx>
Date: Wed, 12 Aug 2009 19:54:14 +0200
Reply-to: "Roland Eggner" <edvx1@xxxxxxxxxxxxxxxxxx>
User-agent: KMail/1.11.2 (Linux/2.6.30.4.roland.1; KDE/4.2.2; i686; ; )
History which lead to actual problem
------------------------------------
On July 4th I switched from kernel 2.6.29.5 to 2.6.29.6.

On July 18th I noticed the first time this unaccountable decrease of free space 
of my root partition /dev/hda7:
For at least several boot-shutdown-cycles it has decreased on every cycle by 
some 1020 … 1030 blocks from originally above 100 MB to 96 MB.
Expected change at most ±1 block.  Neither xfs_check nor xfs_repair -dn could 
detect any flaws.
I booted a sidux image with kernel 2.6.27, mounted /dev/hda7 readonly (actually 
sidux flavour “/dev/sda7”), and compared reported free space ➜ decrease seems 
to occur on umount + system shutdown.  Neither xfs_check nor “xfs_repair -dn” 
running under sidux kernel 2.6.27 could detect any flaws.
Only one other flaw is noteworthy (seperate bugreport scheduled):
Since one of the 2.6.28.? kernels mount procedures require a time randomly 
dithering between less than 1 second and more than 30 seconds with almost no 
harddisk i/o activity, with
NO difference between “mount -a” during boot and manual mounts,
NO difference between mounts of plain and loop-aes-encrypted partitions,
NO difference between kernels 2.6.29.[1-6] and 2.6.30.4.
Only loop mounts of vfat images happen without remarkable delay.
Just after xfs_check and “xfs_repair -dn” have verified a particular 
loop-aes-encrypted filesystem errorfree, kernel complains every time 
“superblock invalid” and mounts it successfully.  Kernel 2.6.30.4 shows the 
same crazy behavior on mounting of the same and additionally another particular 
loop-aes-encrypted filesystem.  Cannot say, if this extreme slow mounts are XFS 
specific, because I do not use any other filesystem on this linux system.

On August 10th — after reading “kernel.org/ChangeLog-2.6.30.bz2:  xfs: fix 
bad_features2 fixups for the root filesystem …” — I switched to kernel 
2.6.30.4, which left the problem UNMODIFIED.

On August 12th free space has decreased to 48 MB, so I am forced to take 
actions.


System details
--------------
System based on Debian testing.
Kernel:  from kernel.org tainted by NVIDIA video driver.
Applied patches:  one from loop-aes-source and another one to fs/namespace.c 
setting MNT_STRICTATIME as default mount option.
smartmontools short selftest reports are errorfree.
“hdparm -W0 /dev/hda” performed by a bootscript and external encrypted 
logdevices are precautions to ensure consistent loop-aes-encrypted xfs 
filesystems — during 1 year of usage I encountered a few power failures, which 
caused “dirty” shutdowns of my notebook but never any filesystem related 
problems :)


#  /usr/sbin/xfs_info /
meta-data=/dev/root              isize=256    agcount=4, agsize=748776 blks
         =                       sectsz=512   attr=2
data     =                       bsize=1024   blocks=2995102, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=1024   ascii-ci=0
log      =internal               bsize=1024   blocks=10240, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0


$  grep /dev/root /proc/mounts
/dev/root / xfs rw,strictatime,attr2,nobarrier,noquota 0 0


At /var /tmp /home are other partitions mounted, therefore the only known write 
activities on root partition apart from atime updates and temporary lockfiles 
are concerning at most 6 blocks:
#  ( export LANGUAGE=en_GB ; find / -ctime -1 -not -type d -print0 | xargs -0 
-- du -bc )
16      /etc/network/run/ifstate
44      /etc/adjtime~
44      /etc/adjtime
23      /etc/resolv.conf
1970    /etc/mtab
2097    total
No known write activities on system startup prior to mount or on shutdown after 
umount in directories on root partition, which are hidden by mounts when system 
is running.


xfs_metadump output from 2 consecutive linux sessions, lzma compressed, 
provided via http-server on request from known XFS developers (preferable gpg 
signed).
Should I perform a xfsdump|mkfs.xfs|xfsrestore-cycle?
Thanks!

-- 
Roland Eggner

Attachment: signature.asc
Description: This is a digitally signed message part.

<Prev in Thread] Current Thread [Next in Thread>