History which lead to actual problem
On July 4th I switched from kernel 184.108.40.206 to 220.127.116.11.
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 18.104.22.168.
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 22.214.171.124 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
126.96.36.199, which left the problem UNMODIFIED.
On August 12th free space has decreased to 48 MB, so I am forced to take
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
# /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 )
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
xfs_metadump output from 2 consecutive linux sessions, lzma compressed,
provided via http-server on request from known XFS developers (preferable gpg
Should I perform a xfsdump|mkfs.xfs|xfsrestore-cycle?
Description: This is a digitally signed message part.