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
signature.asc
Description: This is a digitally signed message part.
|