> And then I see your message that (albeit it not appearing so) the quota has > indeed been enabled for everyone now. Why? Now I can't even try to clean up, > because I can't even edit a big file and replace it with "Temporarily > disabled". I can't remove 100MB to add a small .ini file. I can't > comment out > things that are breaking stuff. My account is completely locked and > anything I > try to touch is immediately wiped. Error/warnings are absent.
I have also been bitten by this. On the one hand, it forced me to go through some archived logs that had gone wild. On the other hand, I wanted to a three-line fix to a tool, and that was a blocker. Not even overwriting a bigger file. Delete a file to free space? Nope, it doesn't allow you to write anything. cp over an existing file? No. dd over an existing file? No, that still usess O_TRUNC. Edit the file with nano and paste the new contents? No dd conv=notrunc *does* work. But it's not trivial to come up. Also, if you got the report: > NFS server ha-nfs.esi not responding still trying > NFS server ha-nfs.esi ok Does it mean everything was processed correctly on disk? I have a process running for 14 hours checking a tar file which took 20 minutes to create. Seems a bit odd :/ On 23/06/12 03:04, Krinkle wrote: > I did not connect the problems I was hearing about from all over with > the quota that was going to come after the weekend. The reason being that I > did > not get any emails regarding limits being reached on /home/krinkle (or the > home > of the MMPs) or any errors when trying to write to a file. > > e.g. $ echo "Hello World" > test.txt > > .. works fine without errors. But looking it up shows it is size 0 bytes. Interesting. I first suspected echo (1) wasn't reporting the problem, but there's no error reported to the application: $ truss /usr/bin/echo "Hello World" > test.txt (...) > write(1, " H e l l o W o r l d\n", 12) = 12 > _exit(0) OTOH, cat reports the error: $ cat /tmp/test.txt > test.txt cat: write error: Disc quota exceeded The system call is failing there: > write(1, " H e l l o W o r l d\n", 12) Err#49 EDQUOT Why such discrepancy? Edit: actually, it seems that it sometimes the write succeeds and in others it fails, with echo exiting in such case with non-zero status (/usr/bin/echo doesn't provide a message in stderr, but bash builtin does). > write(1, " H e l l o W o r l d\n", 12) Err#49 EDQUOT > _exit(1) I think NFS is partly at fault here for the random behavior. The logic seem to be that if the file doesn't exist, you get no error on write, and later close() returns the Err#49 EDQUOT. But if the file already exists, the error is returned directly on the write(). Unlike echo, cat is performing a close (both binary and builtin), which allows it to detect that condition. echo doesn't need to do such close(), but as bash isn't reporting the error on close, it silently fails. Workaround, replace your echo "Hello World" > test.txt calls to echo "Hello World" | cat > test.txt and have fun when someone mocks of you for writing silly code :) _______________________________________________ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
