JFS users needed for testing

KimTjik · 2007-12-31 12:50:04

My background is more in over-clocking hardware, Linux became an interest later. Hence I'm inclined to agree with the "hardware error" theory.

Gullible Jones, your conclusion about what a file-system should or shouldn't do must be based its design and purpose. Let's be honest: IBM wouldn't be using JFS in crucial server environments if it wouldn't have been a stable and high performing file-system. So what does documentation tell about JFS?

If the file system is not deemed clean, indicating that the log was not replayed completely and correctly for some reason or that the file system could not be restored to a consistent state simply by replaying the log, then a full pass of the file system is performed. In performing a full integrity check, the check/repair utility's primary goal is to achieve a reliable file system state to prevent future file system corruption or failures, with a secondary goal of preserving data in the face of corruption. This means the utility may throw away data in the interest of achieving file system consistency.

I'm a newbie when it comes to these kinds of environments, but I would suppose that a consistent file-system will guarantee a more efficient and smoother backup routine. Without doubt a server environment also means several safety measures, like RAID configurations and backups. So to me it looks like JFS is doing exactly what it's supposed to do.

What I would see as plausible reasons for these logs to be uncomplete:
- RAM failure or wrong settings (could also be caused by a malfunctioning memory-controller)
- Hard-drive failure

The last one is peculiar and difficult to pin-point in my experience. I had a hard-drive that ran perfectly well using ext3 - at least I thought so - but would constantly screw up using other options, though recovery usually worked well. Some few applications could rarely freeze the system, like firefox, but I didn't have a clear indication where to look for a solution. To make a long story short: when executing some read/write operations the hard-drive sometimes got it wrong.

JFS probably has flaws like all man-made stuff, but I'm pretty sure we need more than this to conclude that JFS is a bad option. I use JFS in several systems and have so done the past year without noticing any oddity.

It's easy to jump to conclusions, but a lot harder to verify them.

Gullible Jones · 2008-01-31 00:56:48

[Casts resurrect on thread]

I've been experimenting with JFS, and this problem still plagues it. Just a moment ago, a failed suspend caused my machine to lock up; when I forced a reboot, Epiphany's visual configs, history, and cookies were all gone.

KimTjiik: Yes, I realize full well that JFS might be designed to delete files that could be damaged, in order to preserve the integrity of the whole filesystem. However, files that were not being written to and were not cached at the time of a crash should not be damaged, and JFS is the only filesystem where I see that happen - and not just on one machine, but on every machine I've used JFS on for extended periods.

Furthermore, JFS is supposed to place damaged files in lost+found after a fsck. However, a lost+found directory is not generated on filesystem creation.

Edit: And AFAICT lost+found hasn't been deprecated - here, for example, is a thread mentioning it from 2007. I'm starting to wonder if there's something wrong with Arch's jfsutils package, rather than an upstream issue.

Last edited by Gullible Jones (2008-01-31 00:59:30)

byte · 2008-01-31 02:50:16

jfs_fsck creates /lost+found on demand, at least I think that's what it did for me. Btw, I lost Opera's complete history a few days ago after a hard freeze... forget manpages, this is something I really hate.

Gullible Jones · 2008-01-31 06:42:32

Yeah, as far as I can tell jfs_fsck has never created lost+found directories for me, instead simply causing files to vanish - and it looks like it isn't supposed to perma-delete files like that. Something is clearly wrong here.

attila · 2008-01-31 12:08:48

Gullible Jones wrote:

Yeah, as far as I can tell jfs_fsck has never created lost+found directories for me, instead simply causing files to vanish - and it looks like it isn't supposed to perma-delete files like that. Something is clearly wrong here.

The only thing what i can say that during my 2.6.24 tests some days ago my pc hungs severall times and i have had the lost+found directories and files inside of them. Another info: Yesterday the whole town have had an electrical power outage and my server (/boot ext2 and the rest jfs; mail (SMTP and IMAP), News (leafnode), squid and so on) survives without any data loose.

I think all this reports, wether good or bad, depends on more as only the filesystems from my view. No questions, this makes it harder and not better to find the right filesystem.

schivmeister · 2008-01-31 20:27:15

Opera, yeah. And aMSN. There was one more app, but like I said, things have been steady for quite a while. Weird, yes.

Gullible Jones · 2008-01-31 21:11:42

Uh... wrong thread, methinks...

Gullible Jones · 2008-01-31 21:19:55

attila wrote:

Gullible Jones wrote:
Yeah, as far as I can tell jfs_fsck has never created lost+found directories for me, instead simply causing files to vanish - and it looks like it isn't supposed to perma-delete files like that. Something is clearly wrong here.
The only thing what i can say that during my 2.6.24 tests some days ago my pc hungs severall times and i have had the lost+found directories and files inside of them. Another info: Yesterday the whole town have had an electrical power outage and my server (/boot ext2 and the rest jfs; mail (SMTP and IMAP), News (leafnode), squid and so on) survives without any data loose.

That's interesting... I'm still using the stable kernel (2.6.23.14), maybe this is a known issue with the module and fixed in .24?

Let's see, there's no mention of lost+found creation (that is a function of fsck after all), but there's this...

commit 8d8fe64237646fdd2c2de2722ec4189a5999119d
Author: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Date:   Sat Oct 13 12:58:00 2007 -0500

    JFS: Bio cleanup: Replace missing return statements
    
    commit e30408b2a99cb7b8bf529c7dc2328a19d71894cf ("JFS: fix bio-related
    build breakage") removed some "return 0;" statements, rather than
    changing them to null returns.

Could this have fooled jfs_fsck into doing something stupid? I don't know... All I know is that it never creates lost+found for me when dealing with damaged files.

attila · 2008-01-31 21:51:50

@Gullible Jones: I speak only about the 2.6.24 because this was the last crash where something was in lost+found. I can't remember what for a kernel was running as this happened before.

On gname.org you can find two newsgroups (gmane.comp.file-systems.jfs.general and gmane.comp.file-systems.jfs.patches) to get more and better help for your problem.

"Bio cleanup" is a nice title for a fixed bug.:)

schivmeister · 2008-02-01 14:42:48

Gullible Jones wrote:

Uh... wrong thread, methinks...

I was refering to the "lost" files.

Arch Linux

#26 2007-12-31 12:50:04

Re: JFS users needed for testing

#27 2008-01-31 00:56:48

Re: JFS users needed for testing

#28 2008-01-31 02:50:16

Re: JFS users needed for testing

#29 2008-01-31 06:42:32

Re: JFS users needed for testing

#30 2008-01-31 12:08:48

Re: JFS users needed for testing

#31 2008-01-31 20:27:15

Re: JFS users needed for testing

#32 2008-01-31 21:11:42

Re: JFS users needed for testing

#33 2008-01-31 21:19:55

Re: JFS users needed for testing

#34 2008-01-31 21:51:50

Re: JFS users needed for testing

#35 2008-02-01 14:42:48

Re: JFS users needed for testing

Board footer