* Inactive memory keep growing and how to release it?
@ 2013-03-12 6:58 Lenky Gao
2013-03-12 7:41 ` a problem about ext4 zhuyj
2013-03-12 8:37 ` Inactive memory keep growing and how to release it? Zheng Liu
0 siblings, 2 replies; 14+ messages in thread
From: Lenky Gao @ 2013-03-12 6:58 UTC (permalink / raw)
To: linux-ext4
Hi,
When i just run a test on Centos 6.2 as follows:
################################
#!/bin/bash
while true
do
file="/tmp/filetest"
echo $file
dd if=/dev/zero of=${file} bs=512 count=204800 &> /dev/null
sleep 5
done
################################
the inactive memory keep growing:
#cat /proc/meminfo | grep Inactive\(fi
Inactive(file): 420144 kB
...
#cat /proc/meminfo | grep Inactive\(fi
Inactive(file): 554662 kB
...
#cat /proc/meminfo | grep Inactive\(fi
Inactive(file): 882824 kB
and i cannot reclaim it:
# cat /proc/meminfo | grep Inactive\(file\);
Inactive(file): 882824 kB
# sync;
# echo 3 > /proc/sys/vm/drop_caches
# cat /proc/meminfo | grep Inactive\(file\);
Inactive(file): 777664 kB
My file system type is ext3, mounted with the option data=journal and
it is easy to reproduce. If the mount option is data=ordered,
reproducing this problom need more time. Because of the problom, when
in the final situation, i cannot kmalloc a larger contiguous memory,
especially in interrupt context. I have tested on other version
kernel, such as 2.6.30 and 3.6.11, the problom also exists.
Is this a bug?
Or can you give some tips to avoid this?
--
Regards,
Lenky
^ permalink raw reply [flat|nested] 14+ messages in thread* a problem about ext4. 2013-03-12 6:58 Inactive memory keep growing and how to release it? Lenky Gao @ 2013-03-12 7:41 ` zhuyj 2013-03-12 7:49 ` zhuyj 2013-03-12 13:42 ` Theodore Ts'o 2013-03-12 8:37 ` Inactive memory keep growing and how to release it? Zheng Liu 1 sibling, 2 replies; 14+ messages in thread From: zhuyj @ 2013-03-12 7:41 UTC (permalink / raw) To: zhuyj, linux-ext4 Hi, all I install Ubuntu 11.04 on Dell-Latitude-D630. Linux kernel is 2.6.39.4(I compiled) uname -a Linux Dell-Latitude-D630 2.6.39.4-zhuyj26394 #2 SMP Tue Mar 12 13:23:06 CST 2013 i686 i686 i386 GNU/Linux I followed these steps: ****************************Begin*************************************** 1. get ltp-full-20130109.bz2 and run "./configure;make", then we will get fsstress; 2. mount -t tmpfs -o size=512m tmpfs /tmp 3. dd if=/dev/zero of=/tmp/img bs=1024 count=$((500*1024)) 4. ls -lah /tmp/img total 501M drwxrwxrwt 2 root root 60 2013-03-12 15:18 . drwxr-xr-x 23 root root 4.0K 2013-03-12 13:09 .. -rw-r--r-- 1 root root 500M 2013-03-12 15:18 img 5. df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 113317544 6994416 100566868 7% / none 1023772 696 1023076 1% /dev none 1030440 80 1030360 1% /dev/shm none 1030440 92 1030348 1% /var/run none 1030440 0 1030440 0% /var/lock tmpfs 524288 512504 11784 98% /tmp 6. mkfs.ext4 /tmp/img mke2fs 1.41.14 (22-Dec-2010) /tmp/img is not a block special device. Proceed anyway? (y,n) y Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) Stride=0 blocks, Stripe width=0 blocks 128016 inodes, 512000 blocks 25600 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=67633152 63 block groups 8192 blocks per group, 8192 fragments per group 2032 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 30 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. 7. mkdir /tmp/mnt 8. mount -t ext4 -o loop /tmp/img /tmp/mnt 9. df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 113317544 6994424 100566860 7% / none 1023772 696 1023076 1% /dev none 1030440 80 1030360 1% /dev/shm none 1030440 92 1030348 1% /var/run none 1030440 0 1030440 0% /var/lock tmpfs 524288 512504 11784 98% /tmp /dev/loop0 495844 10510 459734 3% /tmp/mnt 10. cd /tmp/mnt; mkdir /tmp/mnt/tmp1 /tmp/mnt/tmp2; cp ~/fsstress /tmp/mnt ./fsstress -c -p 5 -n 10000 -d . -l 0 -s 10M & ./fsstress -c -p 5 -n 10000 -d ./tmp1 -l 0 -s 10M & ./fsstress -c -p 5 -n 10000 -d ./tmp2 -l 0 -s 10M & 11.when the following appears, run "ps;killall fsstress;ps" ./tmp1: No such file or directory ./tmp2: No such file or directory [2]- Exit 1 ./fsstress -c -p 5 -n 10000 -d ./tmp1 -l 0 -s 10M [3]+ Exit 1 ./fsstress -c -p 5 -n 10000 -d ./tmp2 -l 0 -s 10M These messages will appear: ps;killall fsstress;ps PID TTY TIME CMD 1366 pts/0 00:00:01 bash 1600 pts/0 00:00:00 fsstress 1633 pts/0 00:00:07 fsstress 1634 pts/0 00:00:06 fsstress 1635 pts/0 00:00:06 fsstress 1636 pts/0 00:00:07 fsstress 1637 pts/0 00:00:07 fsstress 1640 pts/0 00:00:00 ps [1]+ Terminated ./fsstress -c -p 5 -n 10000 -d . -l 0 -s 10M PID TTY TIME CMD 1366 pts/0 00:00:01 bash 1642 pts/0 00:00:00 ps 12. /bin/sync;/bin/echo 1 > /proc/sys/vm/drop_caches 13. rm -Rf p*;rm -Rf tmp* rm: cannot remove `p0': Directory not empty rm: cannot remove `p1/d99d/d9b4/da40/da71/da74': Directory not empty rm: cannot remove `p2/dc/d79/f56f': Input/output error rm: cannot remove `p2/dc/d79/f362': Input/output error rm: cannot remove `p2/dc/d79/c460': Input/output error rm: cannot remove `p2/dc/d79/cf4': Input/output error rm: cannot remove `p2/dc/d79/f3b0': Input/output error rm: cannot remove `p2/dc/d79/d107/d95e/d7f7/fb50': Input/output error rm: cannot remove `p2/dc/d79/d107/d95e/f99e': Input/output error rm: cannot remove `p2/dc/d79/d107/d95e/fc40': Input/output error rm: cannot remove `p2/dc/d79/d107/f7ab': Input/output error rm: cannot remove `p2/dc/d79/d107/d547/c843': Input/output error rm: cannot remove `p2/dc/d79/d107/d547/c871': Input/output error rm: cannot remove `p2/dc/d79/d107/fa77': Input/output error rm: cannot remove `p2/dc/d79/f12e': Input/output error rm: cannot remove `p2/dc/d79/c623': Input/output error rm: cannot remove `p2/dc/d79/f207': Input/output error rm: cannot remove `p2/dc/d79/c216': Input/output error rm: cannot remove `p2/dc/d79/f23d': Input/output error rm: cannot remove `p2/dc/d79/c250': Input/output error rm: cannot remove `p2/dc/d79/f274': Input/output error rm: cannot remove `p2/dc/d79/f285': Input/output error rm: cannot remove `p2/dc/d79/f2af': Input/output error rm: cannot remove `p2/dc/d79/c2d1': Input/output error rm: cannot remove `p2/dc/d79/c2ee': Input/output error rm: cannot remove `p2/dc/d79/c35a': Input/output error ..... 14. run "dmesg" [ 469.002632] EXT4-fs warning (device loop0): dx_probe:364: Unrecognised inode hash code 12 [ 469.002647] EXT4-fs warning (device loop0): dx_probe:472: Corrupt dir inode 8423, running e2fsck is recommended. [ 469.018830] EXT4-fs error (device loop0): ext4_lookup:1044: inode #8423: comm rm: deleted inode referenced: 8926 [ 469.019792] EXT4-fs error (device loop0): ext4_lookup:1044: inode #8423: comm rm: deleted inode referenced: 8816 [ 469.019950] EXT4-fs error (device loop0): ext4_lookup:1044: inode #8423: comm rm: deleted inode referenced: 8570 [ 469.020729] EXT4-fs error (device loop0): ext4_lookup:1044: inode #8423: comm rm: deleted inode referenced: 7814 [ 469.021227] EXT4-fs error (device loop0): ext4_lookup:1044: inode #8423: comm rm: deleted inode referenced: 9259 [ 469.048610] EXT4-fs error (device loop0): ext4_lookup:1044: inode #10178: comm rm: deleted inode referenced: 7791 [ 469.049919] EXT4-fs error (device loop0): ext4_lookup:1044: inode #10177: comm rm: deleted inode referenced: 8100 [ 469.053826] EXT4-fs error (device loop0): ext4_lookup:1044: inode #10177: comm rm: deleted inode referenced: 8822 [ 469.060481] EXT4-fs error (device loop0): ext4_lookup:1044: inode #8417: comm rm: deleted inode referenced: 8113 [ 469.062336] EXT4-fs warning (device loop0): dx_probe:364: Unrecognised inode hash code 12 [ 469.062349] EXT4-fs warning (device loop0): dx_probe:472: Corrupt dir inode 10163, running e2fsck is recommended. [ 469.065721] EXT4-fs error (device loop0): ext4_lookup:1044: inode #10163: comm rm: deleted inode referenced: 9027 [ 469.066138] EXT4-fs error (device loop0): ext4_lookup:1044: inode #10163: comm rm: deleted inode referenced: 9090 [ 469.067526] EXT4-fs error (device loop0): ext4_lookup:1044: inode #8417: comm rm: deleted inode referenced: 8443 [ 469.068584] EXT4-fs error (device loop0): ext4_lookup:1044: inode #8423: comm rm: deleted inode referenced: 8067 [ 469.069280] EXT4-fs error (device loop0): ext4_lookup:1044: inode #8423: comm rm: deleted inode referenced: 9694 [ 469.069893] EXT4-fs error (device loop0): ext4_lookup:1044: inode #8423: comm rm: deleted inode referenced: 8100 [ 469.070123] EXT4-fs error (device loop0): ext4_lookup:1044: inode #8423: comm rm: deleted inode referenced: 8635 [ 469.070509] EXT4-fs error (device loop0): ext4_lookup:1044: inode #8423: comm rm: deleted inode referenced: 8929 ...... ***************************End********************************************** But if I use ext3, this will not occur. If I do not run "/bin/sync;/bin/echo 1 > /proc/sys/vm/drop_caches", this will not occur. If I use kernel>=3.0, this will not occur. But I use ext4 and run "/bin/sync; /bin/echo 1 > /proc/sys/vm/drop_caches", these error messages. So is this is a bug? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: a problem about ext4. 2013-03-12 7:41 ` a problem about ext4 zhuyj @ 2013-03-12 7:49 ` zhuyj 2013-03-12 8:13 ` zhuyj 2013-03-12 13:42 ` Theodore Ts'o 1 sibling, 1 reply; 14+ messages in thread From: zhuyj @ 2013-03-12 7:49 UTC (permalink / raw) To: zhuyj, linux-ext4 Hi, all Almost 2.6.3x has this problem. Is it a problem? Any reply is appreciated. Zhuyj On 03/12/2013 03:41 PM, zhuyj wrote: > Hi, all > > I install Ubuntu 11.04 on Dell-Latitude-D630. > Linux kernel is 2.6.39.4(I compiled) > > uname -a > Linux Dell-Latitude-D630 2.6.39.4-zhuyj26394 #2 SMP Tue Mar 12 > 13:23:06 CST 2013 i686 i686 i386 GNU/Linux > > I followed these steps: > > ****************************Begin*************************************** > 1. get ltp-full-20130109.bz2 and run "./configure;make", then we will > get fsstress; > > 2. mount -t tmpfs -o size=512m tmpfs /tmp > > 3. dd if=/dev/zero of=/tmp/img bs=1024 count=$((500*1024)) > > 4. ls -lah /tmp/img > > total 501M > drwxrwxrwt 2 root root 60 2013-03-12 15:18 . > drwxr-xr-x 23 root root 4.0K 2013-03-12 13:09 .. > -rw-r--r-- 1 root root 500M 2013-03-12 15:18 img > > 5. df > > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/sda1 113317544 6994416 100566868 7% / > none 1023772 696 1023076 1% /dev > none 1030440 80 1030360 1% /dev/shm > none 1030440 92 1030348 1% /var/run > none 1030440 0 1030440 0% /var/lock > tmpfs 524288 512504 11784 98% /tmp > > 6. mkfs.ext4 /tmp/img > > mke2fs 1.41.14 (22-Dec-2010) > /tmp/img is not a block special device. > Proceed anyway? (y,n) y > Filesystem label= > OS type: Linux > Block size=1024 (log=0) > Fragment size=1024 (log=0) > Stride=0 blocks, Stripe width=0 blocks > 128016 inodes, 512000 blocks > 25600 blocks (5.00%) reserved for the super user > First data block=1 > Maximum filesystem blocks=67633152 > 63 block groups > 8192 blocks per group, 8192 fragments per group > 2032 inodes per group > Superblock backups stored on blocks: > 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 > > Writing inode tables: done > Creating journal (8192 blocks): done > Writing superblocks and filesystem accounting information: done > > This filesystem will be automatically checked every 30 mounts or > 180 days, whichever comes first. Use tune2fs -c or -i to override. > > 7. mkdir /tmp/mnt > > 8. mount -t ext4 -o loop /tmp/img /tmp/mnt > > 9. df > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/sda1 113317544 6994424 100566860 7% / > none 1023772 696 1023076 1% /dev > none 1030440 80 1030360 1% /dev/shm > none 1030440 92 1030348 1% /var/run > none 1030440 0 1030440 0% /var/lock > tmpfs 524288 512504 11784 98% /tmp > /dev/loop0 495844 10510 459734 3% /tmp/mnt > > 10. cd /tmp/mnt; mkdir /tmp/mnt/tmp1 /tmp/mnt/tmp2; cp ~/fsstress > /tmp/mnt > ./fsstress -c -p 5 -n 10000 -d . -l 0 -s 10M & > ./fsstress -c -p 5 -n 10000 -d ./tmp1 -l 0 -s 10M & > ./fsstress -c -p 5 -n 10000 -d ./tmp2 -l 0 -s 10M & > > 11.when the following appears, run "ps;killall fsstress;ps" > ./tmp1: No such file or directory > ./tmp2: No such file or directory > > [2]- Exit 1 ./fsstress -c -p 5 -n 10000 -d ./tmp1 -l > 0 -s 10M > [3]+ Exit 1 ./fsstress -c -p 5 -n 10000 -d ./tmp2 -l > 0 -s 10M > > These messages will appear: > > ps;killall fsstress;ps > PID TTY TIME CMD > 1366 pts/0 00:00:01 bash > 1600 pts/0 00:00:00 fsstress > 1633 pts/0 00:00:07 fsstress > 1634 pts/0 00:00:06 fsstress > 1635 pts/0 00:00:06 fsstress > 1636 pts/0 00:00:07 fsstress > 1637 pts/0 00:00:07 fsstress > 1640 pts/0 00:00:00 ps > [1]+ Terminated ./fsstress -c -p 5 -n 10000 -d . -l 0 -s > 10M > PID TTY TIME CMD > 1366 pts/0 00:00:01 bash > 1642 pts/0 00:00:00 ps > > 12. /bin/sync;/bin/echo 1 > /proc/sys/vm/drop_caches > > 13. rm -Rf p*;rm -Rf tmp* > > rm: cannot remove `p0': Directory not empty > rm: cannot remove `p1/d99d/d9b4/da40/da71/da74': Directory not empty > rm: cannot remove `p2/dc/d79/f56f': Input/output error > rm: cannot remove `p2/dc/d79/f362': Input/output error > rm: cannot remove `p2/dc/d79/c460': Input/output error > rm: cannot remove `p2/dc/d79/cf4': Input/output error > rm: cannot remove `p2/dc/d79/f3b0': Input/output error > rm: cannot remove `p2/dc/d79/d107/d95e/d7f7/fb50': Input/output error > rm: cannot remove `p2/dc/d79/d107/d95e/f99e': Input/output error > rm: cannot remove `p2/dc/d79/d107/d95e/fc40': Input/output error > rm: cannot remove `p2/dc/d79/d107/f7ab': Input/output error > rm: cannot remove `p2/dc/d79/d107/d547/c843': Input/output error > rm: cannot remove `p2/dc/d79/d107/d547/c871': Input/output error > rm: cannot remove `p2/dc/d79/d107/fa77': Input/output error > rm: cannot remove `p2/dc/d79/f12e': Input/output error > rm: cannot remove `p2/dc/d79/c623': Input/output error > rm: cannot remove `p2/dc/d79/f207': Input/output error > rm: cannot remove `p2/dc/d79/c216': Input/output error > rm: cannot remove `p2/dc/d79/f23d': Input/output error > rm: cannot remove `p2/dc/d79/c250': Input/output error > rm: cannot remove `p2/dc/d79/f274': Input/output error > rm: cannot remove `p2/dc/d79/f285': Input/output error > rm: cannot remove `p2/dc/d79/f2af': Input/output error > rm: cannot remove `p2/dc/d79/c2d1': Input/output error > rm: cannot remove `p2/dc/d79/c2ee': Input/output error > rm: cannot remove `p2/dc/d79/c35a': Input/output error > ..... > > 14. run "dmesg" > > [ 469.002632] EXT4-fs warning (device loop0): dx_probe:364: > Unrecognised inode hash code 12 > [ 469.002647] EXT4-fs warning (device loop0): dx_probe:472: Corrupt > dir inode 8423, running e2fsck is recommended. > [ 469.018830] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #8423: comm rm: deleted inode referenced: 8926 > [ 469.019792] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #8423: comm rm: deleted inode referenced: 8816 > [ 469.019950] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #8423: comm rm: deleted inode referenced: 8570 > [ 469.020729] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #8423: comm rm: deleted inode referenced: 7814 > [ 469.021227] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #8423: comm rm: deleted inode referenced: 9259 > [ 469.048610] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #10178: comm rm: deleted inode referenced: 7791 > [ 469.049919] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #10177: comm rm: deleted inode referenced: 8100 > [ 469.053826] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #10177: comm rm: deleted inode referenced: 8822 > [ 469.060481] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #8417: comm rm: deleted inode referenced: 8113 > [ 469.062336] EXT4-fs warning (device loop0): dx_probe:364: > Unrecognised inode hash code 12 > [ 469.062349] EXT4-fs warning (device loop0): dx_probe:472: Corrupt > dir inode 10163, running e2fsck is recommended. > [ 469.065721] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #10163: comm rm: deleted inode referenced: 9027 > [ 469.066138] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #10163: comm rm: deleted inode referenced: 9090 > [ 469.067526] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #8417: comm rm: deleted inode referenced: 8443 > [ 469.068584] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #8423: comm rm: deleted inode referenced: 8067 > [ 469.069280] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #8423: comm rm: deleted inode referenced: 9694 > [ 469.069893] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #8423: comm rm: deleted inode referenced: 8100 > [ 469.070123] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #8423: comm rm: deleted inode referenced: 8635 > [ 469.070509] EXT4-fs error (device loop0): ext4_lookup:1044: inode > #8423: comm rm: deleted inode referenced: 8929 > ...... > > ***************************End********************************************** > > > But if I use ext3, this will not occur. > If I do not run "/bin/sync;/bin/echo 1 > /proc/sys/vm/drop_caches", > this will not occur. > If I use kernel>=3.0, this will not occur. > > But I use ext4 and run "/bin/sync; /bin/echo 1 > > /proc/sys/vm/drop_caches", these error messages. > > So is this is a bug? > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: a problem about ext4. 2013-03-12 7:49 ` zhuyj @ 2013-03-12 8:13 ` zhuyj 0 siblings, 0 replies; 14+ messages in thread From: zhuyj @ 2013-03-12 8:13 UTC (permalink / raw) To: zhuyj, linux-ext4 But if I use ext3, this will not occur. If I do not run "/bin/sync;/bin/echo 1 > /proc/sys/vm/drop_caches", this will not occur. If I use kernel>=3.0, this will not occur. If I use ext4 and run "/bin/sync; /bin/echo 1 > /proc/sys/vm/drop_caches", these error messages will appear. So is this is a bug? On 03/12/2013 03:49 PM, zhuyj wrote: > Hi, all > > Almost 2.6.3x has this problem. Is it a problem? > > Any reply is appreciated. > Zhuyj > > On 03/12/2013 03:41 PM, zhuyj wrote: >> Hi, all >> >> I install Ubuntu 11.04 on Dell-Latitude-D630. >> Linux kernel is 2.6.39.4(I compiled) >> >> uname -a >> Linux Dell-Latitude-D630 2.6.39.4-zhuyj26394 #2 SMP Tue Mar 12 >> 13:23:06 CST 2013 i686 i686 i386 GNU/Linux >> >> I followed these steps: >> >> ****************************Begin*************************************** >> 1. get ltp-full-20130109.bz2 and run "./configure;make", then we will >> get fsstress; >> >> 2. mount -t tmpfs -o size=512m tmpfs /tmp >> >> 3. dd if=/dev/zero of=/tmp/img bs=1024 count=$((500*1024)) >> >> 4. ls -lah /tmp/img >> >> total 501M >> drwxrwxrwt 2 root root 60 2013-03-12 15:18 . >> drwxr-xr-x 23 root root 4.0K 2013-03-12 13:09 .. >> -rw-r--r-- 1 root root 500M 2013-03-12 15:18 img >> >> 5. df >> >> Filesystem 1K-blocks Used Available Use% Mounted on >> /dev/sda1 113317544 6994416 100566868 7% / >> none 1023772 696 1023076 1% /dev >> none 1030440 80 1030360 1% /dev/shm >> none 1030440 92 1030348 1% /var/run >> none 1030440 0 1030440 0% /var/lock >> tmpfs 524288 512504 11784 98% /tmp >> >> 6. mkfs.ext4 /tmp/img >> >> mke2fs 1.41.14 (22-Dec-2010) >> /tmp/img is not a block special device. >> Proceed anyway? (y,n) y >> Filesystem label= >> OS type: Linux >> Block size=1024 (log=0) >> Fragment size=1024 (log=0) >> Stride=0 blocks, Stripe width=0 blocks >> 128016 inodes, 512000 blocks >> 25600 blocks (5.00%) reserved for the super user >> First data block=1 >> Maximum filesystem blocks=67633152 >> 63 block groups >> 8192 blocks per group, 8192 fragments per group >> 2032 inodes per group >> Superblock backups stored on blocks: >> 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 >> >> Writing inode tables: done >> Creating journal (8192 blocks): done >> Writing superblocks and filesystem accounting information: done >> >> This filesystem will be automatically checked every 30 mounts or >> 180 days, whichever comes first. Use tune2fs -c or -i to override. >> >> 7. mkdir /tmp/mnt >> >> 8. mount -t ext4 -o loop /tmp/img /tmp/mnt >> >> 9. df >> Filesystem 1K-blocks Used Available Use% Mounted on >> /dev/sda1 113317544 6994424 100566860 7% / >> none 1023772 696 1023076 1% /dev >> none 1030440 80 1030360 1% /dev/shm >> none 1030440 92 1030348 1% /var/run >> none 1030440 0 1030440 0% /var/lock >> tmpfs 524288 512504 11784 98% /tmp >> /dev/loop0 495844 10510 459734 3% /tmp/mnt >> >> 10. cd /tmp/mnt; mkdir /tmp/mnt/tmp1 /tmp/mnt/tmp2; cp ~/fsstress >> /tmp/mnt >> ./fsstress -c -p 5 -n 10000 -d . -l 0 -s 10M & >> ./fsstress -c -p 5 -n 10000 -d ./tmp1 -l 0 -s 10M & >> ./fsstress -c -p 5 -n 10000 -d ./tmp2 -l 0 -s 10M & >> >> 11.when the following appears, run "ps;killall fsstress;ps" >> ./tmp1: No such file or directory >> ./tmp2: No such file or directory >> >> [2]- Exit 1 ./fsstress -c -p 5 -n 10000 -d ./tmp1 >> -l 0 -s 10M >> [3]+ Exit 1 ./fsstress -c -p 5 -n 10000 -d ./tmp2 >> -l 0 -s 10M >> >> These messages will appear: >> >> ps;killall fsstress;ps >> PID TTY TIME CMD >> 1366 pts/0 00:00:01 bash >> 1600 pts/0 00:00:00 fsstress >> 1633 pts/0 00:00:07 fsstress >> 1634 pts/0 00:00:06 fsstress >> 1635 pts/0 00:00:06 fsstress >> 1636 pts/0 00:00:07 fsstress >> 1637 pts/0 00:00:07 fsstress >> 1640 pts/0 00:00:00 ps >> [1]+ Terminated ./fsstress -c -p 5 -n 10000 -d . -l 0 >> -s 10M >> PID TTY TIME CMD >> 1366 pts/0 00:00:01 bash >> 1642 pts/0 00:00:00 ps >> >> 12. /bin/sync;/bin/echo 1 > /proc/sys/vm/drop_caches >> >> 13. rm -Rf p*;rm -Rf tmp* >> >> rm: cannot remove `p0': Directory not empty >> rm: cannot remove `p1/d99d/d9b4/da40/da71/da74': Directory not empty >> rm: cannot remove `p2/dc/d79/f56f': Input/output error >> rm: cannot remove `p2/dc/d79/f362': Input/output error >> rm: cannot remove `p2/dc/d79/c460': Input/output error >> rm: cannot remove `p2/dc/d79/cf4': Input/output error >> rm: cannot remove `p2/dc/d79/f3b0': Input/output error >> rm: cannot remove `p2/dc/d79/d107/d95e/d7f7/fb50': Input/output error >> rm: cannot remove `p2/dc/d79/d107/d95e/f99e': Input/output error >> rm: cannot remove `p2/dc/d79/d107/d95e/fc40': Input/output error >> rm: cannot remove `p2/dc/d79/d107/f7ab': Input/output error >> rm: cannot remove `p2/dc/d79/d107/d547/c843': Input/output error >> rm: cannot remove `p2/dc/d79/d107/d547/c871': Input/output error >> rm: cannot remove `p2/dc/d79/d107/fa77': Input/output error >> rm: cannot remove `p2/dc/d79/f12e': Input/output error >> rm: cannot remove `p2/dc/d79/c623': Input/output error >> rm: cannot remove `p2/dc/d79/f207': Input/output error >> rm: cannot remove `p2/dc/d79/c216': Input/output error >> rm: cannot remove `p2/dc/d79/f23d': Input/output error >> rm: cannot remove `p2/dc/d79/c250': Input/output error >> rm: cannot remove `p2/dc/d79/f274': Input/output error >> rm: cannot remove `p2/dc/d79/f285': Input/output error >> rm: cannot remove `p2/dc/d79/f2af': Input/output error >> rm: cannot remove `p2/dc/d79/c2d1': Input/output error >> rm: cannot remove `p2/dc/d79/c2ee': Input/output error >> rm: cannot remove `p2/dc/d79/c35a': Input/output error >> ..... >> >> 14. run "dmesg" >> >> [ 469.002632] EXT4-fs warning (device loop0): dx_probe:364: >> Unrecognised inode hash code 12 >> [ 469.002647] EXT4-fs warning (device loop0): dx_probe:472: Corrupt >> dir inode 8423, running e2fsck is recommended. >> [ 469.018830] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #8423: comm rm: deleted inode referenced: 8926 >> [ 469.019792] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #8423: comm rm: deleted inode referenced: 8816 >> [ 469.019950] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #8423: comm rm: deleted inode referenced: 8570 >> [ 469.020729] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #8423: comm rm: deleted inode referenced: 7814 >> [ 469.021227] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #8423: comm rm: deleted inode referenced: 9259 >> [ 469.048610] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #10178: comm rm: deleted inode referenced: 7791 >> [ 469.049919] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #10177: comm rm: deleted inode referenced: 8100 >> [ 469.053826] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #10177: comm rm: deleted inode referenced: 8822 >> [ 469.060481] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #8417: comm rm: deleted inode referenced: 8113 >> [ 469.062336] EXT4-fs warning (device loop0): dx_probe:364: >> Unrecognised inode hash code 12 >> [ 469.062349] EXT4-fs warning (device loop0): dx_probe:472: Corrupt >> dir inode 10163, running e2fsck is recommended. >> [ 469.065721] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #10163: comm rm: deleted inode referenced: 9027 >> [ 469.066138] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #10163: comm rm: deleted inode referenced: 9090 >> [ 469.067526] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #8417: comm rm: deleted inode referenced: 8443 >> [ 469.068584] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #8423: comm rm: deleted inode referenced: 8067 >> [ 469.069280] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #8423: comm rm: deleted inode referenced: 9694 >> [ 469.069893] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #8423: comm rm: deleted inode referenced: 8100 >> [ 469.070123] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #8423: comm rm: deleted inode referenced: 8635 >> [ 469.070509] EXT4-fs error (device loop0): ext4_lookup:1044: inode >> #8423: comm rm: deleted inode referenced: 8929 >> ...... >> >> ***************************End********************************************** >> >> >> But if I use ext3, this will not occur. >> If I do not run "/bin/sync;/bin/echo 1 > /proc/sys/vm/drop_caches", >> this will not occur. >> If I use kernel>=3.0, this will not occur. >> >> But I use ext4 and run "/bin/sync; /bin/echo 1 > >> /proc/sys/vm/drop_caches", these error messages. >> >> So is this is a bug? >> > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: a problem about ext4. 2013-03-12 7:41 ` a problem about ext4 zhuyj 2013-03-12 7:49 ` zhuyj @ 2013-03-12 13:42 ` Theodore Ts'o 2013-03-13 3:24 ` Ext4:can not rm directories on 2.6.3x zhuyj 1 sibling, 1 reply; 14+ messages in thread From: Theodore Ts'o @ 2013-03-12 13:42 UTC (permalink / raw) To: zhuyj; +Cc: zhuyj, linux-ext4 On Tue, Mar 12, 2013 at 03:41:31PM +0800, zhuyj wrote: > If I use kernel>=3.0, this will not occur. Sounds like this is a problem in 2.6.39 that has since been fixed in newer kernels. > So is this is a bug? Sure looks like it's a bug. :-) There are so many distributions and other old embedded systems, etc., using older kernels that there's just no way that upstream developers can try to debug every single older kernel --- and 2.6.39 isn't even a kernel that is being supported by a volunteer as a long-term supported kernel. See http://www.kernel.org for a list of kernels which are supported as long-term kernels, and even then, please remember that unless fixes are automatically backported, or someone manually backports a fix that doesn't automatically apply to an older kernel, it's not going to happen..... Regards, - Ted P.S. Your problem appears to be completely unrelated to the thread which you replied to. This makes it hard for us to keep track of questions/bug reports which users submit. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Ext4:can not rm directories on 2.6.3x 2013-03-12 13:42 ` Theodore Ts'o @ 2013-03-13 3:24 ` zhuyj 2013-03-15 7:16 ` zhuyj 0 siblings, 1 reply; 14+ messages in thread From: zhuyj @ 2013-03-13 3:24 UTC (permalink / raw) To: Theodore Ts'o; +Cc: zhuyj, linux-ext4 OK. Thanks a lot. This bug can happen on Ubuntu 11.04,10.10 with kernel 2.6.3x. Follow the above steps, this bug can be reproduced. Anyone has the same experience? On 03/12/2013 09:42 PM, Theodore Ts'o wrote: > On Tue, Mar 12, 2013 at 03:41:31PM +0800, zhuyj wrote: >> If I use kernel>=3.0, this will not occur. > Sounds like this is a problem in 2.6.39 that has since been fixed in > newer kernels. > >> So is this is a bug? > Sure looks like it's a bug. :-) > > There are so many distributions and other old embedded systems, etc., > using older kernels that there's just no way that upstream developers > can try to debug every single older kernel --- and 2.6.39 isn't even a > kernel that is being supported by a volunteer as a long-term supported > kernel. > > See http://www.kernel.org for a list of kernels which are supported as > long-term kernels, and even then, please remember that unless fixes > are automatically backported, or someone manually backports a fix that > doesn't automatically apply to an older kernel, it's not going to > happen..... > > Regards, > > - Ted > > P.S. Your problem appears to be completely unrelated to the thread > which you replied to. This makes it hard for us to keep track of > questions/bug reports which users submit. > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ext4:can not rm directories on 2.6.3x 2013-03-13 3:24 ` Ext4:can not rm directories on 2.6.3x zhuyj @ 2013-03-15 7:16 ` zhuyj 2013-03-15 14:53 ` Theodore Ts'o 0 siblings, 1 reply; 14+ messages in thread From: zhuyj @ 2013-03-15 7:16 UTC (permalink / raw) To: zhuyj; +Cc: Theodore Ts'o, linux-ext4 Hi, all The two patches can fix this problem. ext4: Fix fs corruption when make_indexed_dir() fails ext4: don't dereference null pointer when make_indexed_dir() fails If any one comes across this problem, he can apply the above two patches. Zhuyj On 03/13/2013 11:24 AM, zhuyj wrote: > OK. Thanks a lot. > This bug can happen on Ubuntu 11.04,10.10 with kernel 2.6.3x. > Follow the above steps, this bug can be reproduced. > > Anyone has the same experience? > > On 03/12/2013 09:42 PM, Theodore Ts'o wrote: >> On Tue, Mar 12, 2013 at 03:41:31PM +0800, zhuyj wrote: >>> If I use kernel>=3.0, this will not occur. >> Sounds like this is a problem in 2.6.39 that has since been fixed in >> newer kernels. >> >>> So is this is a bug? >> Sure looks like it's a bug. :-) >> >> There are so many distributions and other old embedded systems, etc., >> using older kernels that there's just no way that upstream developers >> can try to debug every single older kernel --- and 2.6.39 isn't even a >> kernel that is being supported by a volunteer as a long-term supported >> kernel. >> >> See http://www.kernel.org for a list of kernels which are supported as >> long-term kernels, and even then, please remember that unless fixes >> are automatically backported, or someone manually backports a fix that >> doesn't automatically apply to an older kernel, it's not going to >> happen..... >> >> Regards, >> >> - Ted >> >> P.S. Your problem appears to be completely unrelated to the thread >> which you replied to. This makes it hard for us to keep track of >> questions/bug reports which users submit. >> > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ext4:can not rm directories on 2.6.3x 2013-03-15 7:16 ` zhuyj @ 2013-03-15 14:53 ` Theodore Ts'o 2013-03-15 14:56 ` Willy Tarreau 2013-03-15 15:12 ` Paul Gortmaker 0 siblings, 2 replies; 14+ messages in thread From: Theodore Ts'o @ 2013-03-15 14:53 UTC (permalink / raw) To: zhuyj; +Cc: linux-ext4, stable, Willy Tarreau, Paul Gortmaker [-- Attachment #1: Type: text/plain, Size: 748 bytes --] On Fri, Mar 15, 2013 at 03:16:52PM +0800, zhuyj wrote: > Hi, all > > The two patches can fix this problem. > ext4: Fix fs corruption when make_indexed_dir() fails > ext4: don't dereference null pointer when make_indexed_dir() fails Thanks, Zhujh for figuring this out. Those two patches weren't taggled with cc: stable@vger.kernel.org, but they probably should have been. Since they first appeared in v3.0, the two long-term stable kernels that would benefit with these patches are v3.0.x and v3.2.x. Willy, Paul, would you consider cherry-picking the following commits for your respective stable kernels? git cherry-pick 7ad8e4e6ae2a7c95445ee1715b1714106fb95037 git cherry-pick 6976a6f2acde2b0443cd64f1d08af90630e4ce81 Thanks!! - Ted [-- Attachment #2: 0001-ext4-Fix-fs-corruption-when-make_indexed_dir-fails.patch --] [-- Type: text/x-diff, Size: 1573 bytes --] >From 7ad8e4e6ae2a7c95445ee1715b1714106fb95037 Mon Sep 17 00:00:00 2001 From: Jan Kara <jack@suse.cz> Date: Tue, 3 May 2011 11:05:55 -0400 Subject: [PATCH] ext4: Fix fs corruption when make_indexed_dir() fails When make_indexed_dir() fails (e.g. because of ENOSPC) after it has allocated block for index tree root, we did not properly mark all changed buffers dirty. This lead to only some of these buffers being written out and thus effectively corrupting the directory. Fix the issue by marking all changed data dirty even in the error failure case. Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> --- fs/ext4/namei.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 67fd0b0..cadf04b 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -1414,9 +1414,19 @@ static int make_indexed_dir(handle_t *handle, struct dentry *dentry, frame->bh = bh; bh = bh2; de = do_split(handle,dir, &bh, frame, &hinfo, &retval); - dx_release (frames); - if (!(de)) + if (!de) { + /* + * Even if the block split failed, we have to properly write + * out all the changes we did so far. Otherwise we can end up + * with corrupted filesystem. + */ + ext4_mark_inode_dirty(handle, dir); + ext4_handle_dirty_metadata(handle, dir, frame->bh); + ext4_handle_dirty_metadata(handle, dir, bh); + dx_release(frames); return retval; + } + dx_release(frames); retval = add_dirent_to_buf(handle, dentry, inode, de, bh); brelse(bh); -- 1.7.12.rc0.22.gcdd159b [-- Attachment #3: 0001-ext4-don-t-dereference-null-pointer-when-make_indexe.patch --] [-- Type: text/x-diff, Size: 1293 bytes --] >From 6976a6f2acde2b0443cd64f1d08af90630e4ce81 Mon Sep 17 00:00:00 2001 From: Allison Henderson <achender@linux.vnet.ibm.com> Date: Sun, 15 May 2011 00:19:41 -0400 Subject: [PATCH] ext4: don't dereference null pointer when make_indexed_dir() fails Fix for a null pointer bug found while running punch hole tests Signed-off-by: Allison Henderson <achender@us.ibm.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> --- fs/ext4/namei.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 3c7a06e..b754b77 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -1413,6 +1413,10 @@ static int make_indexed_dir(handle_t *handle, struct dentry *dentry, frame->at = entries; frame->bh = bh; bh = bh2; + + ext4_handle_dirty_metadata(handle, dir, frame->bh); + ext4_handle_dirty_metadata(handle, dir, bh); + de = do_split(handle,dir, &bh, frame, &hinfo, &retval); if (!de) { /* @@ -1421,8 +1425,6 @@ static int make_indexed_dir(handle_t *handle, struct dentry *dentry, * with corrupted filesystem. */ ext4_mark_inode_dirty(handle, dir); - ext4_handle_dirty_metadata(handle, dir, frame->bh); - ext4_handle_dirty_metadata(handle, dir, bh); dx_release(frames); return retval; } -- 1.7.12.rc0.22.gcdd159b ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: Ext4:can not rm directories on 2.6.3x 2013-03-15 14:53 ` Theodore Ts'o @ 2013-03-15 14:56 ` Willy Tarreau 2013-03-15 14:59 ` Theodore Ts'o 2013-03-15 15:12 ` Paul Gortmaker 1 sibling, 1 reply; 14+ messages in thread From: Willy Tarreau @ 2013-03-15 14:56 UTC (permalink / raw) To: Theodore Ts'o; +Cc: zhuyj, linux-ext4, stable, Paul Gortmaker On Fri, Mar 15, 2013 at 10:53:14AM -0400, Theodore Ts'o wrote: > On Fri, Mar 15, 2013 at 03:16:52PM +0800, zhuyj wrote: > > Hi, all > > > > The two patches can fix this problem. > > ext4: Fix fs corruption when make_indexed_dir() fails > > ext4: don't dereference null pointer when make_indexed_dir() fails > > Thanks, Zhujh for figuring this out. Those two patches weren't > taggled with cc: stable@vger.kernel.org, but they probably should have > been. Since they first appeared in v3.0, the two long-term stable > kernels that would benefit with these patches are v3.0.x and v3.2.x. > > Willy, Paul, would you consider cherry-picking the following commits > for your respective stable kernels? > > git cherry-pick 7ad8e4e6ae2a7c95445ee1715b1714106fb95037 > git cherry-pick 6976a6f2acde2b0443cd64f1d08af90630e4ce81 Yes of course ! Thank you Ted! Willy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ext4:can not rm directories on 2.6.3x 2013-03-15 14:56 ` Willy Tarreau @ 2013-03-15 14:59 ` Theodore Ts'o 0 siblings, 0 replies; 14+ messages in thread From: Theodore Ts'o @ 2013-03-15 14:59 UTC (permalink / raw) To: Willy Tarreau; +Cc: zhuyj, linux-ext4, stable, Paul Gortmaker On Fri, Mar 15, 2013 at 03:56:04PM +0100, Willy Tarreau wrote: > > Thanks, Zhujh for figuring this out. Those two patches weren't > > taggled with cc: stable@vger.kernel.org, but they probably should have > > been. Since they first appeared in v3.0, the two long-term stable > > kernels that would benefit with these patches are v3.0.x and v3.2.x. Oops, sorry, that should have read 2.6.32 and 2.6.34. :-) > > Willy, Paul, would you consider cherry-picking the following commits > > for your respective stable kernels? > > > > git cherry-pick 7ad8e4e6ae2a7c95445ee1715b1714106fb95037 > > git cherry-pick 6976a6f2acde2b0443cd64f1d08af90630e4ce81 > > Yes of course ! Great, thanks!! - Ted ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ext4:can not rm directories on 2.6.3x 2013-03-15 14:53 ` Theodore Ts'o 2013-03-15 14:56 ` Willy Tarreau @ 2013-03-15 15:12 ` Paul Gortmaker 1 sibling, 0 replies; 14+ messages in thread From: Paul Gortmaker @ 2013-03-15 15:12 UTC (permalink / raw) To: Theodore Ts'o; +Cc: zhuyj, linux-ext4, stable, Willy Tarreau On 13-03-15 10:53 AM, Theodore Ts'o wrote: > On Fri, Mar 15, 2013 at 03:16:52PM +0800, zhuyj wrote: >> Hi, all >> >> The two patches can fix this problem. >> ext4: Fix fs corruption when make_indexed_dir() fails >> ext4: don't dereference null pointer when make_indexed_dir() fails > > Thanks, Zhujh for figuring this out. Those two patches weren't > taggled with cc: stable@vger.kernel.org, but they probably should have > been. Since they first appeared in v3.0, the two long-term stable > kernels that would benefit with these patches are v3.0.x and v3.2.x. > > Willy, Paul, would you consider cherry-picking the following commits > for your respective stable kernels? Both queued for 2.6.34.15 Thanks, Paul. -- > > git cherry-pick 7ad8e4e6ae2a7c95445ee1715b1714106fb95037 > git cherry-pick 6976a6f2acde2b0443cd64f1d08af90630e4ce81 > > Thanks!! > > - Ted > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Inactive memory keep growing and how to release it? 2013-03-12 6:58 Inactive memory keep growing and how to release it? Lenky Gao 2013-03-12 7:41 ` a problem about ext4 zhuyj @ 2013-03-12 8:37 ` Zheng Liu 2013-03-12 8:48 ` Lenky Gao 2013-03-14 8:00 ` Lenky Gao 1 sibling, 2 replies; 14+ messages in thread From: Zheng Liu @ 2013-03-12 8:37 UTC (permalink / raw) To: Lenky Gao; +Cc: linux-ext4 Hi Gao, On Tue, Mar 12, 2013 at 02:58:24PM +0800, Lenky Gao wrote: > Hi, > > When i just run a test on Centos 6.2 as follows: > ################################ > #!/bin/bash > > while true > do > > file="/tmp/filetest" > > echo $file > > dd if=/dev/zero of=${file} bs=512 count=204800 &> /dev/null > > sleep 5 > done > ################################ > > the inactive memory keep growing: > > #cat /proc/meminfo | grep Inactive\(fi > Inactive(file): 420144 kB > ... > #cat /proc/meminfo | grep Inactive\(fi > Inactive(file): 554662 kB > ... > #cat /proc/meminfo | grep Inactive\(fi > Inactive(file): 882824 kB > > and i cannot reclaim it: > > # cat /proc/meminfo | grep Inactive\(file\); > Inactive(file): 882824 kB > # sync; > # echo 3 > /proc/sys/vm/drop_caches > # cat /proc/meminfo | grep Inactive\(file\); > Inactive(file): 777664 kB > > My file system type is ext3, mounted with the option data=journal and > it is easy to reproduce. If the mount option is data=ordered, > reproducing this problom need more time. Because of the problom, when > in the final situation, i cannot kmalloc a larger contiguous memory, > especially in interrupt context. I have tested on other version > kernel, such as 2.6.30 and 3.6.11, the problom also exists. > > Is this a bug? I don't think it is a bug. If I understand correctly, when you try to reclaim memory (sync and drop caches), the test script is still running, right? If so, that means that some memory will be re-dirtied again. So the number of inactive pages could not reduce as you expected. Regards, - Zheng ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Inactive memory keep growing and how to release it? 2013-03-12 8:37 ` Inactive memory keep growing and how to release it? Zheng Liu @ 2013-03-12 8:48 ` Lenky Gao 2013-03-14 8:00 ` Lenky Gao 1 sibling, 0 replies; 14+ messages in thread From: Lenky Gao @ 2013-03-12 8:48 UTC (permalink / raw) To: Lenky Gao, linux-ext4 On Tue, Mar 12, 2013 at 4:37 PM, Zheng Liu <gnehzuil.liu@gmail.com> wrote: > Hi Gao, > I don't think it is a bug. If I understand correctly, when you try to > reclaim memory (sync and drop caches), the test script is still running, > right? If so, that means that some memory will be re-dirtied again. So > the number of inactive pages could not reduce as you expected. The test script has stopped. Some log messages came from my UML Linux as follows: ... /sdb/file_test total used free shared buffers cached Mem: 182 179 2 0 10 13 -/+ buffers/cache: 155 27 Swap: 0 0 0 /sdb/file_test ^C [root@localhost ~]# [root@localhost ~]# sync; [root@localhost ~]# echo 3 > /proc/sys/vm/drop_caches [root@localhost ~]# [root@localhost ~]# echo 3 > /proc/sys/vm/drop_caches [root@localhost ~]# sync; [root@localhost ~]# echo 3 > /proc/sys/vm/drop_caches [root@localhost ~]# free -m total used free shared buffers cached Mem: 182 157 25 0 0 3 -/+ buffers/cache: 153 28 Swap: 0 0 0 [root@localhost ~]# cat /proc/meminfo | grep Inac Inactive: 124756 kB Inactive(anon): 1408 kB Inactive(file): 123348 kB [root@localhost ~]# uname -a Linux localhost.localdomain 2.6.30.8 #20 Mon Mar 11 07:04:06 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]# mount | grep sdb /dev/ubdb1 on /sdb type ext3 (rw,data=journal) [root@localhost ~]# cat ./test_write_disk.sh #!/bin/bash while true do # file="/sdb/file_`date +%y%m%d%k%m%s`" file="/sdb/file_test" echo $file dd if=/dev/zero of=${file} bs=512 count=20480 &> /dev/null # sync # cat /proc/meminfo | grep Inactive\(file\) free -m # rm -fr ${file} done -- Regards, Lenky ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Inactive memory keep growing and how to release it? 2013-03-12 8:37 ` Inactive memory keep growing and how to release it? Zheng Liu 2013-03-12 8:48 ` Lenky Gao @ 2013-03-14 8:00 ` Lenky Gao 1 sibling, 0 replies; 14+ messages in thread From: Lenky Gao @ 2013-03-14 8:00 UTC (permalink / raw) To: linux-ext4 Hi Everyone, Maybe i have found the answer for this question. The author of the JBD have explained in the comments: /* * When an ext3-ordered file is truncated, it is possible that many pages are * not successfully freed, because they are attached to a committing transaction. * After the transaction commits, these pages are left on the LRU, with no * ->mapping, and with attached buffers. These pages are trivially reclaimable * by the VM, but their apparent absence upsets the VM accounting, and it makes * the numbers in /proc/meminfo look odd. ... */ static void release_buffer_page(struct buffer_head *bh) { struct page *page; ... But my new question is why not free those pages after the transaction commits? -- Regards, Lenky ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-03-15 15:13 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-03-12 6:58 Inactive memory keep growing and how to release it? Lenky Gao 2013-03-12 7:41 ` a problem about ext4 zhuyj 2013-03-12 7:49 ` zhuyj 2013-03-12 8:13 ` zhuyj 2013-03-12 13:42 ` Theodore Ts'o 2013-03-13 3:24 ` Ext4:can not rm directories on 2.6.3x zhuyj 2013-03-15 7:16 ` zhuyj 2013-03-15 14:53 ` Theodore Ts'o 2013-03-15 14:56 ` Willy Tarreau 2013-03-15 14:59 ` Theodore Ts'o 2013-03-15 15:12 ` Paul Gortmaker 2013-03-12 8:37 ` Inactive memory keep growing and how to release it? Zheng Liu 2013-03-12 8:48 ` Lenky Gao 2013-03-14 8:00 ` Lenky Gao
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).