http://oss.sgi.com/bugzilla/show_bug.cgi?id=887
Summary: over max icount inode allocation
Product: XFS
Version: unspecified
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P5
Component: XFS kernel code
AssignedTo: xfs-masters@xxxxxxxxxxx
ReportedBy: sbrodsky@xxxxxxx
Estimated Hours: 0.0
Classification: Unclassified
I create a small xfs filesytem:
mkfs -t xfs -f /dev/sdh1
meta-data=/dev/sdh1 isize=256 agcount=2, agsize=4096 blks
= sectsz=512 attr=0
data = bsize=4096 blocks=8192, imaxpct=25
= sunit=0 swidth=0 blks, unwritten=1
naming =version 2 bsize=4096
log =internal log bsize=4096 blocks=1200, version=1
= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0
mounting the filesystem and doing a stat -f /mnt
sbrodsky@xfsqa-xe1:~> stat -f /mnt
File: "/mnt"
ID: 871 Namelen: 255 Type: xfs
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 6992 Free: 6559 Available: 6559
Inodes: Total: 32768 Free: 32765
says I have 32765 free inodes
(the max icount in the mount table is set to 32765)
I run the following script:
#!/bin/sh
i="0"
while [ $i -lt 10000000000 ]
do
touch /mnt/$i
if [ $? -ne 0 ]
then
exit 1
fi
i=$[$i+1]
done
When I stat the filesystem again I see this:
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 6992 Free: 4189 Available: 4189
Inodes: Total: 32768 Free: -292
the free inodes goes negative.
the script reported back
touch: cannot touch `/mnt/33085': No space left on device
which is 292 files over the max icount value.
This has been seen on 2.6.16 all the way to 26.33
I believe it is the fact that the code uses sb_icount + new allocation >
max_icount to determine that we have inode space available. However the
sb_icount in the super block is not updated until commit time and sb_icount can
be stale.
--
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
|