[mythtv-users] Is my JFS broken ?

[r2d2]

In reply to Graham

> The zero byte file is going to be an entry in an existing inode (or
equivalent for jfs), and
> the file with contents is going to require the allocation of new space for
the contents.
> From memory (and its been a long time since I used jfs) it keeps a log of
the available
> spaces on the disk, so if that log is inaccessible (or locked) for some
reason, then
> attempting to allocate new space will have exactly the impact you're
seeing.
Thank you for the explanation.

> Those would certainly have caused the corruption, but in theory once the
fsck was complete,
> it should be "ok" again.  If you reboot and then try and create that 10M
file without doing
> anything else first, does that bomb out still?
No.
After each reboot, it works for a while and then "bomb out" when moving
files.

> That (and the lack of errors) implies that it's not actually a hardware
problem.
Couldn't it be random memory error ?

> One last check (that will probably take quite a while) would be to attempt
to read the block
> device using dd - that'll tell you if the problem is with jfs or at a
lower level.  Just "dd
> if=<block device> of=/dev/null bs=16M" and leave it running overnight ;)
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.

> If the reboot doesn't fix it (and possibly even if it does) it may make
sense to stop
> everything and force a full fsck (even if the OS thinks the partition is
clean). Unmount it,
> and then "fsck.jfs -v -f <device> | tee /tmp/fsck_log".  That'll log to a
file as well as
> chucking it to the screen, which may be of use to someone that knows JFS
well.
The reboot fix the problem but I "fsck" the filesystem as you adviced. Here
is the result :

fsck.jfs version 1.1.11, 05-Jun-2006
processing started: 8/21/2008 13.13.32
The current device is:  /dev/mapper/vgmythtv01-lvmythtv3
Open(...READ/WRITE EXCLUSIVE...) returned rc = 0
Primary superblock is valid.
The type of file system for the device is JFS.
Block size in bytes:  4096
Filesystem size in blocks:  263344128
**Phase 0 - Replay Journal Log
LOGREDO:  Log already redone!
logredo returned rc = 0
**Phase 1 - Check Blocks, Files/Directories, and  Directory Entries
**Phase 2 - Count links
**Phase 3 - Duplicate Block Rescan and Directory Connectedness
**Phase 4 - Report Problems
**Phase 5 - Check Connectivity
**Phase 6 - Perform Approved Corrections
**Phase 7 - Rebuild File/Directory Allocation Maps
**Phase 8 - Rebuild Disk Allocation Maps
Filesystem Summary:
Blocks in use for inodes:  992
Inode count:  7936
File count:  3113
Directory count:  128
Block count:  263344128
Free block count:  44005953
1053376512 kilobytes total disk space.
     1104 kilobytes in 128 directories.
877154816 kilobytes in 3113 user files.
        0 kilobytes in extended attributes
        0 kilobytes in access control lists
   198988 kilobytes reserved for system use.
176023812 kilobytes are available for use.
Filesystem is clean.
All observed inconsistencies have been repaired.
Filesystem has been marked clean.
**** Filesystem was modified. ****
processing terminated:  8/21/2008 13:13:49  with return code: 0  exit code:
0.

I already have manually applied fsck on the fs before it "bomb out".

Kind regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20080821/dceff6ab/attachment.htm