I just wiped the dust off my monitor (a Samsung T260), using the supplied cleaning cloth. I even read the instructions and kept within the limits of spraying my cloth with water 4-6 times. When I sat down again, the monitor was off. I pressed the “Source” button a couple of times to cycle through the available inputs, hoping to find either the laptop or the desktop, both connected to the monitor. No reaction. I pressed all the other buttons, nothing either. I disconnected and reconnected power. I checked that the power cable hadn’t magically unplugged itself and the inputs were still firmly attached. I started looking for a power switch in all the usual and unusual places, but failed. Defeated, I turned to the laptop and downloaded the monitor’s manual, only to find the obvious explanation:
There is a power “switch”, but it’s a touch sensitive area on the front side of the monitor (in contrast to all the other buttons, which are physical buttons hidden on the side of the monitor). It’s even marked with the universal “power” sign, but it’s quite easy to misread that as a label for the power LED that’s located a couple of millimeters below. But yeah, fine monitor. And it’s probably obvious to members of the iPhone generation.
So, my application doesn’t work. Somehow, a file I want to store stuff in always ends up empty. I dig through the code. I debug the code. I strace the code and look for other access to the file. It looks perfectly okay, I never touch the file again after a nice create/write/close without any errors. Standing by as the file is written, I see this:
[root@somewhere somewhere]# while true; do ls -l --time-style=full foo; sleep .5; done
ls: foo: No such file or directory
-rw-r--r-- 1 nfsnobody nfsnobody 0 2009-07-24 13:54:36.117293000 +0200 foo
-rw-r--r-- 1 nfsnobody nfsnobody 65 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r-- 1 nfsnobody nfsnobody 65 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r-- 1 nfsnobody nfsnobody 65 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r-- 1 nfsnobody nfsnobody 65 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r-- 1 nfsnobody nfsnobody 65 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r-- 1 nfsnobody nfsnobody 65 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r-- 1 nfsnobody nfsnobody 0 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r-- 1 nfsnobody nfsnobody 0 2009-07-24 13:54:39.544909000 +0200 foo
-rw-r--r-- 1 nfsnobody nfsnobody 0 2009-07-24 13:54:39.544909000 +0200 foo
Since this happens even when I kill my application while the file is still in its non-empty state, I start getting suspicious about the underlying filesystem (as you’ve probably noticed by now, NFS). Now, look at this:
[root@somewhere somewhere]# echo "0123456789012345678901234567890123456789012345678901234567891234" > aFile
[root@somewhere somewhere]# cat aFile
[root@somewhere somewhere]# ls -l aFile
-rw-r--r-- 1 nfsnobody nfsnobody 0 Jul 24 11:27 aFile
But…
[root@somewhere somewhere]# echo "012345678901234567890123456789012345678901234567890123456789123" > aFile
[root@somewhere somewhere]# ls -l aFile
-rw-r--r-- 1 nfsnobody nfsnobody 64 Jul 24 11:27 aFile
[root@somewhere somewhere]# cat aFile
012345678901234567890123456789012345678901234567890123456789123
[root@somewhere somewhere]# ls -l aFile
-rw-r--r-- 1 nfsnobody nfsnobody 64 Jul 24 11:27 aFile
Heh. So writing a file of 64 bytes or less works, while anything larger gets reset to zero sooner or later. Of course, that begs the question of what happens when appending to a 64 byte file…
[root@somewhere somewhere]# echo "012345678901234567890123456789012345678901234567890123456789123" > aFile
[root@somewhere somewhere]# cat aFile
012345678901234567890123456789012345678901234567890123456789123
[root@somewhere somewhere]# echo "X" >> aFile
[root@somehwere somewhere]# cat aFile
012345678901234567890123456789012345678901234567890123456789123
Lovely, isn’t it? At this point, I want to investigate this thing a bit more exhaustively and try to write a shell script in that fateful directory. When I’m done, it has of course grown over the magical 64 byte boundary, and vim warns me that
"test.sh" E667: Fsync failed
WARNING: Original file may be lost or damaged
don't quit the editor until the file is successfully written!
An error at last. So I start googling around for failed fsyncs on NFS, and it turns out that they like to crop up when the NFS developers break the kernel code. However, when I strace my vim to find the error, it finally dawns on me what the actual problem is:
fsync(4) = -1 EDQUOT (Disk quota exceeded)
Ah yes, quotas.
[root@somewhere somewhere]# quota nfsnobody
Disk quotas for user nfsnobody (uid 65534):
Filesystem blocks quota limit grace files quota limit grace
nfshome0:/vol/vol1/nfshome0
2150400* 2048000 2150400 736 102400 122880
Sure enough, this weird behaviour turns up when the user is over its quota. Also, interestingly, the ability to even write the long files in the first place seems to be limited to bash – for example:
[root@somewhere somewhere]# dd if=/dev/zero of=foo bs=65 count=1
1+0 records in
1+0 records out
dd: closing output file `foo': Disk quota exceeded
And sure enough, an strace of this dd shows that it gets an error on close:
close(1) = -1 EDQUOT (Disk quota exceeded)
Amazingly, bash’s echo somehow seems to bypass this check, since the appropriate section of its strace reads:
open("foo", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
fcntl64(1, F_GETFD) = 0
fcntl64(1, F_DUPFD, 10) = 10
fcntl64(1, F_GETFD) = 0
fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
dup2(3, 1) = 1
close(3) = 0
fstat64(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ddb000
write(1, "01234567890123456789012345678901"..., 66) = 66
dup2(10, 1) = 1
fcntl64(10, F_GETFD) = 0x1 (flags FD_CLOEXEC)
close(10) = 0
Huh? I can’t seem to make sense of this. But anyway, I’ll go pester the NFS admins to increase nfsnobody’s quota a bit now and alter my code to check all the fstreams’ failbits again after closing them, then hope that my application doesn’t use whatever magic bash uses to bypass the error. You’re welcome to earn major geek points in the comments by explaining this to me.
M-x phases-of-moon
Of course with optional prefix argument for specifying year and month. Ha, TextPad losers – can your text editor help you find out that your first full moon was three days after your birth?
