Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

xfs seems to use 15-30% more disk space than the files require:

# du
0       .
# dd if=/dev/zero of=test bs=1M count=5k
5120+0 records in
5120+0 records out
5368709120 bytes (5,4 GB) copied, 10,527 s, 510 MB/s
# ls -l
total 8388608
-rw-r--r-- 1 root root 5368709120 Oct 19 16:04 test
# du
8388608 .

It seems to do that to a certain degree for the whole file system. This filesystem reports disk full when adding files less than 1% of the file system's size:

# df
/dev/sdb6  40957913088 35624042728 5333870360  87% /xfs-export

Is it caused by some fancy option when doing mkxfs (similar to the reserved 5% in ext2)?

# uname -a
Linux server 2.6.39-bpo.2-amd64 #1 SMP Tue Jul 26 10:35:23 UTC 2011 x86_64 GNU/Linux
share|improve this question
    
Do you see the same effect with small files (1 KB) in the same directory? –  Nils Oct 19 '11 at 18:39
    
After latest upgrade+reboot the problem disappeared. I can no longer reproduce the error. As I cannot follow up on any suggestions I vote for closing the question. –  Ole Tange Jan 29 '12 at 17:07
    
Why do you not provide some details about your problem as answer to your own question here? It is probably interesting to know (for others) that there might be problems with the version you used prior to the upgrade... –  Nils Jan 29 '12 at 20:50
add comment

2 Answers

I strongly suspect you're seeing such strange numbers because you have the environmental variable BLOCKSIZE set to 640. BLOCKSIZE affects what ls, du, and df print. Set BLOCKSIZE to "1024" or "1k" and you should see the output you expect.

share|improve this answer
add comment

It has been a long time since I could reproduce this problem. I think I got it now:

$ ls -l
total 0
$ dd if=/dev/md0 >> a bs=10000k &
$ ls -l
total 9111552
-rw-r--r-- 1 rt rt 5816320000 Jan  7 23:31 a

It stays at this until dd finishes (or is killed) - even if dd is suspended. After that things look normal:

$ kill %1; ls -l
total 20120000
-rw-r--r-- 1 rt rt 20602880000 Jan  7 23:33 a

So it simply looks as if xfs is reserving space for the file to expand on.

The dd in the question finishes, but there might have been some other files open that could justify the reservation.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.