I am using RHEL (CentOS) 5.5 with kernel? 2.6.18-194.17.4.el5? and ext4. I
posted to RHEL bugzilla and they requested me to post it here.
I wrote a program that fallocates space for a file. It does not know the
file
size apriori and uses a heuristic. If the final file size is less than the
allocated space, I free up the extra space with truncate. I found that
freeing
up did not work so I ended up doing two truncates -- truncate(size+1)
followed
by truncate(size) as suggested in
http://kerneltrap.org/mailarchive/linux-ext4/2009/7/21/6243463.
I now find that the freed space is not given back till a unmount+ mount.
I detected this by finding disks full even though the used space was lesser.
I did the standard tests
1. Stopped all program having handles open to files on that partition
2. Verified with lsof that there are no open handles to files in that
partition
???? Still there was a mismatch. e.g. see below
e.g.
bash-3.2# mount | grep hadoop_data
/dev/mapper/vg0-data on /hadoop_data type ext4
(rw,noatime,barrier=0,journal_checksum)
bash-3.2# mount | grep hadoop_data
/dev/mapper/vg0-data on /hadoop_data type ext4
(rw,noatime,barrier=0,journal_checksum)
bash-3.2# du -h /hadoop_data/ | tail -1
328G??? /hadoop_data/
bash-3.2# df -h /hadoop_data/
Filesystem??????????? Size? Used Avail Use% Mounted on
/dev/mapper/vg0-data? 745G? 592G? 117G? 84% /hadoop_data
???????? After unmount + mount, I find this
bash-3.2# umount /hadoop_data/
bash-3.2# mount /hadoop_data/
bash-3.2# df -h /hadoop_data/
Filesystem??????????? Size? Used Avail Use% Mounted on
/dev/mapper/vg0-data? 745G? 328G? 380G? 47% /hadoop_data
Version-Release number of selected component (if applicable):
RHEL (CentOS) 5.5 with kernel?? 2.6.18-194.17.4.el5? and ext4.
How reproducible:
All the time.
Steps to Reproduce:
? Have a program
1.? Open a file on ext4 partition
2. Fallocate space for that file? say 20 GB
3. Write data to the file? (but less than the allocated space) say 10 GB
4. Close the file
5. Call truncate(file-path, size+1), truncate(file-path,size) on that file
to
give up the space (observed that the space is given up using filefrag)
6. Use du and df on that ext4 partition to find that the mismatch
-George
George Kola wrote:
> I am using RHEL (CentOS) 5.5 with kernel 2.6.18-194.17.4.el5 and ext4. I
> posted to RHEL bugzilla and they requested me to post it here.
>
...
> Steps to Reproduce:
> Have a program
> 1. Open a file on ext4 partition
# touch testfile
> 2. Fallocate space for that file say 20 GB
# /root/fallocate -l 20g testfile
# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 30G 21G 7.7G 73% /mnt/test
# du -h testfile
21G testfile
> 3. Write data to the file (but less than the allocated space) say 10 GB
# dd if=/dev/zero of=testfile bs=10M count=1024 conv=notrunc
10737418240 bytes (11 GB) copied, 125.522 seconds, 85.5 MB/s
# du -h testfile
21G testfile
# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 30G 21G 7.7G 73% /mnt/test
> 4. Close the file
> 5. Call truncate(file-path, size+1), truncate(file-path,size) on that file
> to
> give up the space (observed that the space is given up using filefrag)
10g size I assume? Is the below representative?
# /root/truncate 10737418241 testfile
# ls -l testfile
-rw-r--r-- 1 root root 10737418241 Oct 29 13:48 testfile
# /root/truncate 10737418240 testfile
# ls -l testfile
-rw-r--r-- 1 root root 10737418240 Oct 29 13:48 testfile
> 6. Use du and df on that ext4 partition to find that the mismatch
# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 30G 11G 18G 37% /mnt/test
# du -h testfile
11G testfile
# uname -a
Linux bear-05 2.6.18-225.el5 #1 SMP Mon Sep 27 10:32:19 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Seems to work here, though there are ext4 updates in that kernel.
-Eric
>
>
> -George
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Are you using FALLOC_FL_KEEP_SIZE? If so, commit
a379cd1d6bb00f9f5d2759d4a5621a884df5914e fixed a bug with this (but I
don't know offhand which kernel this went into).
Curt
On Fri, Oct 29, 2010 at 11:26 AM, George Kola <[email protected]> wrote:
> I am using RHEL (CentOS) 5.5 with kernel? 2.6.18-194.17.4.el5? and ext4. I
> posted to RHEL bugzilla and they requested me to post it here.
>
> I wrote a program that fallocates space for a file. It does not know the
> file
> size apriori and uses a heuristic. If the final file size is less than the
> allocated space, I free up the extra space with truncate. I found that
> freeing
> up did not work so I ended up doing two truncates -- truncate(size+1)
> followed
> by truncate(size) as suggested in
> http://kerneltrap.org/mailarchive/linux-ext4/2009/7/21/6243463.
>
> I now find that the freed space is not given back till a unmount+ mount.
> I detected this by finding disks full even though the used space was lesser.
>
> I did the standard tests
> 1. Stopped all program having handles open to files on that partition
> 2. Verified with lsof that there are no open handles to files in that
> partition
> ???? Still there was a mismatch. e.g. see below
>
>
> e.g.
> bash-3.2# mount | grep hadoop_data
> /dev/mapper/vg0-data on /hadoop_data type ext4
> (rw,noatime,barrier=0,journal_checksum)
> bash-3.2# mount | grep hadoop_data
> /dev/mapper/vg0-data on /hadoop_data type ext4
> (rw,noatime,barrier=0,journal_checksum)
> bash-3.2# du -h /hadoop_data/ | tail -1
> 328G??? /hadoop_data/
> bash-3.2# df -h /hadoop_data/
> Filesystem??????????? Size? Used Avail Use% Mounted on
> /dev/mapper/vg0-data? 745G? 592G? 117G? 84% /hadoop_data
>
> ???????? After unmount + mount, I find this
>
> bash-3.2# umount /hadoop_data/
> bash-3.2# mount /hadoop_data/
> bash-3.2# df -h /hadoop_data/
> Filesystem??????????? Size? Used Avail Use% Mounted on
> /dev/mapper/vg0-data? 745G? 328G? 380G? 47% /hadoop_data
>
>
>
>
>
> Version-Release number of selected component (if applicable):
>
> RHEL (CentOS) 5.5 with kernel?? 2.6.18-194.17.4.el5? and ext4.
>
>
> How reproducible:
> ?All the time.
>
>
>
> Steps to Reproduce:
> ? Have a program
> 1.? Open a file on ext4 partition
> 2. Fallocate space for that file? say 20 GB
> 3. Write data to the file? (but less than the allocated space) say 10 GB
> 4. Close the file
> 5. Call truncate(file-path, size+1), truncate(file-path,size) on that file
> to
> give up the space (observed that the space is given up using filefrag)
> 6. Use du and df on that ext4 partition to find that the mismatch
>
>
> -George
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
Hi Erik,
?? ? ?Thanks for replying. How to get a hold of kernel??2.6.18-225.el5
? ?I found?2.6.18-227?at
http://people.redhat.com/jwilson/el5/227.el5/x86_64/
I tried it and the bug is fixed is?2.6.18-227. ? Thanks for your help.
This may be off-topic -- how do I find the changes from
2.6.18-194.17.4 to?2.6.18-225 (or?2.6.18-227) ? I just want to know
what other changes I am installing in addition to the bug fix.
Thanks,
George
p/s: yes I am using FALLOC_FL_KEEP_SIZE.
On Fri, Oct 29, 2010 at 11:39 AM, Eric Sandeen <[email protected]> wrote:
>
> George Kola wrote:
> > I am using RHEL (CentOS) 5.5 with kernel ?2.6.18-194.17.4.el5 ?and ext4. I
> > posted to RHEL bugzilla and they requested me to post it here.
> >
>
> ...
>
> > Steps to Reproduce:
> > ? Have a program
> > 1. ?Open a file on ext4 partition
>
> # touch testfile
>
> > 2. Fallocate space for that file ?say 20 GB
>
> # /root/fallocate -l 20g testfile
> # df -h .
> Filesystem ? ? ? ? ? ?Size ?Used Avail Use% Mounted on
> /dev/sdb2 ? ? ? ? ? ? ?30G ? 21G ?7.7G ?73% /mnt/test
> # du -h testfile
> 21G ? ? testfile
>
> > 3. Write data to the file ?(but less than the allocated space) say 10 GB
>
> # dd if=/dev/zero of=testfile bs=10M count=1024 conv=notrunc
> 10737418240 bytes (11 GB) copied, 125.522 seconds, 85.5 MB/s
> # du -h testfile
> 21G ? ? testfile
> # df -h .
> Filesystem ? ? ? ? ? ?Size ?Used Avail Use% Mounted on
> /dev/sdb2 ? ? ? ? ? ? ?30G ? 21G ?7.7G ?73% /mnt/test
>
> > 4. Close the file
> > 5. Call truncate(file-path, size+1), truncate(file-path,size) on that file
> > to
> > give up the space (observed that the space is given up using filefrag)
>
> 10g size I assume? Is the below representative?
>
> # /root/truncate 10737418241 testfile
> # ls -l testfile
> -rw-r--r-- 1 root root 10737418241 Oct 29 13:48 testfile
> # /root/truncate 10737418240 testfile
> # ls -l testfile
> -rw-r--r-- 1 root root 10737418240 Oct 29 13:48 testfile
>
> > 6. Use du and df on that ext4 partition to find that the mismatch
>
> # df -h .
> Filesystem ? ? ? ? ? ?Size ?Used Avail Use% Mounted on
> /dev/sdb2 ? ? ? ? ? ? ?30G ? 11G ? 18G ?37% /mnt/test
>
> # du -h testfile
> 11G ? ? testfile
>
> # uname -a
> Linux bear-05 2.6.18-225.el5 #1 SMP Mon Sep 27 10:32:19 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
>
> Seems to work here, though there are ext4 updates in that kernel.
>
> -Eric
>
> >
> >
> > -George
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > the body of a message to [email protected]
> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
George Kola wrote:
> Hi Erik,
> Thanks for replying. How to get a hold of kernel 2.6.18-225.el5 ?
It (or a later kernel) will be available to RHEL subscribers when released,
and CentOS at some time after that, on their schedule.
> I found 2.6.18-227 at http://people.redhat.com/jwilson/el5/227.el5/x86_64/
> I tried it and the bug is fixed is 2.6.18-227. Thanks for your help.
>
> This may be off-topic -- how do I find the changes from 2.6.18-194.17.4
> to 2.6.18-225 (or 2.6.18-227) ? I just want to know what other changes I
> am installing in addition to the bug fix.
The kernel RPM changelog has a general description of changes, usually
with reference to bug numbers.
-Eric
>
> Thanks,
> George
>
>
> On Fri, Oct 29, 2010 at 11:39 AM, Eric Sandeen <[email protected]
> <mailto:[email protected]>> wrote:
>
> George Kola wrote:
> > I am using RHEL (CentOS) 5.5 with kernel 2.6.18-194.17.4.el5 and
> ext4. I
> > posted to RHEL bugzilla and they requested me to post it here.
> >
>
> ...
>
> > Steps to Reproduce:
> > Have a program
> > 1. Open a file on ext4 partition
>
> # touch testfile
>
> > 2. Fallocate space for that file say 20 GB
>
> # /root/fallocate -l 20g testfile
> # df -h .
> Filesystem Size Used Avail Use% Mounted on
> /dev/sdb2 30G 21G 7.7G 73% /mnt/test
> # du -h testfile
> 21G testfile
>
> > 3. Write data to the file (but less than the allocated space) say
> 10 GB
>
> # dd if=/dev/zero of=testfile bs=10M count=1024 conv=notrunc
> 10737418240 bytes (11 GB) copied, 125.522 seconds, 85.5 MB/s
> # du -h testfile
> 21G testfile
> # df -h .
> Filesystem Size Used Avail Use% Mounted on
> /dev/sdb2 30G 21G 7.7G 73% /mnt/test
>
> > 4. Close the file
> > 5. Call truncate(file-path, size+1), truncate(file-path,size) on
> that file
> > to
> > give up the space (observed that the space is given up using filefrag)
>
> 10g size I assume? Is the below representative?
>
> # /root/truncate 10737418241 testfile
> # ls -l testfile
> -rw-r--r-- 1 root root 10737418241 Oct 29 13:48 testfile
> # /root/truncate 10737418240 testfile
> # ls -l testfile
> -rw-r--r-- 1 root root 10737418240 Oct 29 13:48 testfile
>
> > 6. Use du and df on that ext4 partition to find that the mismatch
>
> # df -h .
> Filesystem Size Used Avail Use% Mounted on
> /dev/sdb2 30G 11G 18G 37% /mnt/test
>
> # du -h testfile
> 11G testfile
>
> # uname -a
> Linux bear-05 2.6.18-225.el5 #1 SMP Mon Sep 27 10:32:19 EDT 2010
> x86_64 x86_64 x86_64 GNU/Linux
>
> Seems to work here, though there are ext4 updates in that kernel.
>
> -Eric
>
> >
> >
> > -George
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> linux-ext4" in
> > the body of a message to [email protected]
> <mailto:[email protected]>
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>