<div dir="ltr">In reply to Graham<br><br>> The zero byte file is going to be an entry in an existing inode (or equivalent for jfs), and<br>
> the file with contents is going to require the allocation of new space for the contents.<br>
> From memory (and its been a long time since I used jfs) it keeps a log of the available<br>
> spaces on the disk, so if that log is inaccessible (or locked) for some reason, then<br>
> attempting to allocate new space will have exactly the impact you're seeing.<br>Thank you for the explanation.<br><br>> Those would certainly have caused the corruption, but in theory once the fsck was complete,<br>
> it should be "ok" again. If you reboot and then try and create that 10M file without doing<br>
> anything else first, does that bomb out still?<br>No.<br>After each reboot, it works for a while and then "bomb out" when moving files.<br><br>> That (and the lack of errors) implies that it's not actually a hardware problem.<br>
Couldn't it be random memory error ?<br><br>> One last check (that will probably take quite a while) would be to attempt to read the block<br>
> device using dd - that'll tell you if the problem is with jfs or at a lower level. Just "dd<br>
> if=<block device> of=/dev/null bs=16M" and leave it running overnight ;)<br>I had the same idea and made dd if=<block device> of=/dev/null on all the partitions involved in the filesystem and works fine.<br>
<br>> If the reboot doesn't fix it (and possibly even if it does) it may make sense to stop<br>
> everything and force a full fsck (even if the OS thinks the partition is clean). Unmount it,<br>
> and then "fsck.jfs -v -f <device> | tee /tmp/fsck_log". That'll log to a file as well as<br>
> chucking it to the screen, which may be of use to someone that knows JFS well.<br>The reboot fix the problem but I "fsck" the filesystem as you adviced. Here is the result :<br><br>fsck.jfs version 1.1.11, 05-Jun-2006<br>
processing started: 8/21/2008 13.13.32<br>The current device is: /dev/mapper/vgmythtv01-lvmythtv3<br>Open(...READ/WRITE EXCLUSIVE...) returned rc = 0<br>Primary superblock is valid.<br>The type of file system for the device is JFS.<br>
Block size in bytes: 4096<br>Filesystem size in blocks: 263344128<br>**Phase 0 - Replay Journal Log<br>LOGREDO: Log already redone!<br>logredo returned rc = 0<br>**Phase 1 - Check Blocks, Files/Directories, and Directory Entries<br>
**Phase 2 - Count links<br>**Phase 3 - Duplicate Block Rescan and Directory Connectedness<br>**Phase 4 - Report Problems<br>**Phase 5 - Check Connectivity<br>**Phase 6 - Perform Approved Corrections<br>**Phase 7 - Rebuild File/Directory Allocation Maps<br>
**Phase 8 - Rebuild Disk Allocation Maps<br>Filesystem Summary:<br>Blocks in use for inodes: 992<br>Inode count: 7936<br>File count: 3113<br>Directory count: 128<br>Block count: 263344128<br>Free block count: 44005953<br>
1053376512 kilobytes total disk space.<br> 1104 kilobytes in 128 directories.<br>877154816 kilobytes in 3113 user files.<br> 0 kilobytes in extended attributes<br> 0 kilobytes in access control lists<br>
198988 kilobytes reserved for system use.<br>176023812 kilobytes are available for use.<br>Filesystem is clean.<br>All observed inconsistencies have been repaired.<br>Filesystem has been marked clean.<br>**** Filesystem was modified. ****<br>
processing terminated: 8/21/2008 13:13:49 with return code: 0 exit code: 0.<br><br>I already have manually applied fsck on the fs before it "bomb out".<br><br>Kind regards.<br></div>