Paul E Condon wrote: > I rather like the idea of having a 5% safety allowance, and having %use > report 100% when there is still 25GB available on a 500GB disk. That is > explained somewhere and is easy to understand and appreciate. But rm id > SLOW on these big disks. I've been watching the progress of rm more > often than I'd like,
I have been noticing that the ext4 w/ fsync fiasco is making everything very much slower while saying that it is trying to make things faster. The irony is tragic. I don't know if that is what you are suffering from but it is potentially possible. > and I noticed that my mental extrapolations of when the process > would be done weren't giving the correct answer, and it was because > of this bug, so I report. Sometimes it is a bug. Sometimes it is not. Thank you for the report just the same. In any case I apologize for not spending the time to completely understand your report before sending my reply. So often people don't take minfree into consideration and so I pointed to the FAQ on the topic. While the other numbers are just reported from statfs the use percentage is calculated. Sorry for getting ahead of myself. I agree with your analysis that used / (used + available) in your case of 310726424 / ( 310726424 + 144929512 ) = 0.68193 as you reported which is not equal to the 69% that the tool emitted. I looked at the code and if I am following the correct code path then it is basically doing the following: used = f_blocks available_to_root = f_bfree available = f_bavail nonroot_total = used + available u100 = used * 100 pct = u100 / nonroot_total + (u100 % nonroot_total != 0) Knowing the values returned from the statfs system call would fill in the values for f_blocks, f_bfree, and f_bavail and should allow us to know how this calculation is processed. Again, my apologies for not fully understanding the nature of your bug report at that time. > > To see the values that the kernel is returning to df's statfs call > > please run the following command and report the contents of the file. > > > > $ strace -v -e trace=statfs -o /tmp/df.strace.out df /dev/sde1 > > I don't have strace installed on the computer were this is happening. > I attempted to install but the computer crashed will running aptitude. Instead of running aptitude (which because of your words makes me think it ran out of memory and got the oom killer involved) you could copy the strace deb over and then install it directly with dpkg -i which would use much less memory and very likely succeed where aptitude failed. You could even help aptitude along with aptitude download strace and then dpkg -i strace*.deb at that point. Just ideas for you. Alternatively it would be relatively easy to put together a very small C program that printed the results of the statfs call directly. Or perhaps print it from perl's syscall interface. Please let me know if you have too much trouble getting strace installed and I will suggest something. Bob -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
