ext4 fallocate+truncate not freeing up allocated space

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

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

Quoted 3 lines · George Kola

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.

...

Quoted 3 lines

Steps to Reproduce:
  Have a program
1.  Open a file on ext4 partition

# touch testfile

Quoted 1 line

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

Quoted 1 line

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

Quoted 4 lines

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

Quoted 1 line

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

Quoted 10 lines

-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

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

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