headers
rothojo | 5 Jan 2004 19:25

JFS Problem

JFS is a well filesystem. But some problems occur: When running chkdsk on a server drive d:, I got the message 
very soon:
JFS0148: CHKDSK Unrecoverable error reading M from d. CHKDSK CANNOT
CONTINUE.
 Some explanation got on Internet:
"CHKDSK has encountered an I/O error.
ACTION: Correct the condition that caused the I/O error on the partition, and
then restart CHKDSK.
I'd be checking physical connections to drives M and d.
If these partitions are on a different harddisk to other partitions, you could be
looking at a harddisk that is about to fail."
 There are no I/O errors i logs or any messages on server concerning
I/O. Disks are on a Netfinity 5500 M20, ServeRAID-4H with battery backup,
five disks channel 2, SCSI ID 0 to 4, Bios 6.00.31, configured into to
logical drives. There are no drives named M.
 When running jfschk32.exe, message:
JFS0068:CHKDSK Superblock is corrupt and cannot be repaired because
both primary and secondary copies are corrupt. CHKDSK CANNOT CONTINUE.
 There is no problem reading or saving info on disk. All programs are running also, but it's frustrating that
I 
can't run chkdsk to ensure that everything is OK.
 Any suggestions?
 Just run a new format d: /fs:jfs  ??
  Rolf-Thore
 The non-spesialist

-------------------------------------------------
WebMail fra Tele2 http://www.tele2.no
-------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Kleikamp | 5 Jan 2004 20:09
Picon
Favicon

Re: JFS Problem

I'm sorry this mailing list is specific to JFS on Linux.  I don't know
if any OS/2 experts monitor it.

On Mon, 2004-01-05 at 12:25, rothojo <at> c2i.net wrote:
> JFS is a well filesystem. But some problems occur: When running chkdsk on a server drive d:, I got the
message 
> very soon:
> JFS0148: CHKDSK Unrecoverable error reading M from d. CHKDSK CANNOT
> CONTINUE.
>  Some explanation got on Internet:
> "CHKDSK has encountered an I/O error.
> ACTION: Correct the condition that caused the I/O error on the partition, and
> then restart CHKDSK.
> I'd be checking physical connections to drives M and d.
> If these partitions are on a different harddisk to other partitions, you could be
> looking at a harddisk that is about to fail."
>  There are no I/O errors i logs or any messages on server concerning
> I/O. Disks are on a Netfinity 5500 M20, ServeRAID-4H with battery backup,
> five disks channel 2, SCSI ID 0 to 4, Bios 6.00.31, configured into to
> logical drives. There are no drives named M.

I believe the M refers to metadata.  I'm not sure why it isn't spelled
out.

>  When running jfschk32.exe, message:
> JFS0068:CHKDSK Superblock is corrupt and cannot be repaired because
> both primary and secondary copies are corrupt. CHKDSK CANNOT CONTINUE.
>  There is no problem reading or saving info on disk. All programs are running also, but it's frustrating
that I 
> can't run chkdsk to ensure that everything is OK.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Kleikamp | 5 Jan 2004 20:36
Picon
Favicon

Re: resize feature

On Fri, 2003-12-19 at 15:28, SyvertsonJ wrote:
> What version was the resize version added.

I believe it was added in 1.0.21, and has been in all kernels since
2.4.20.

> 
> With Redhat Enterprise, I can run jfs as an "unsupported" version.
> 
> It has the jfs-utils version 1.1.2-2 rpm installed.

The resize function is not tied to the utilities.  You resize a mounted
partition with the command "mount -oremount,resize /mountpoint" (after
the block device has been extended).

> 
> What version was the "resize" capability added to jfs?
> 
> Also, can anyone tell me if they think that jfs 1.1.2 is a stable release
> suitable for running a database on top of it?

Version 1.1.2 is the version of the utilities.  The kernel code is
merged into the mainline kernel and is not ties to the JFS release
numbers.  (There is kernel code available from our website that is
released as 1.1.2, but I don't think any distros are getting the code
from there anymore.)

That said, the JFS code in RHEL is quite up to date and stable.  I
haven't used it very extensively myself, though.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Kleikamp | 6 Jan 2004 17:35
Picon
Favicon

Re: Linux device number bug report

On Tue, 2003-12-30 at 18:43, WEI Yongjun wrote:
> Hello,
> 
> I have some questions about device number extension.
> 
> In Linux kernel 2.6, device number will be extended from 16-bit to
> 32-bit. All utilities and libraries should make corresponding
> extension for this new feature in kernel 2.6. 
> 
> I find that “jfsutils-1.1.4” uses dev_t and operates the device number
> as 16-bit.
> In file libfs/devices.h: 53
>     static inline int32_t dev_to_kdev(dev_t rdev)
>     {
>          return (major(rdev) << 8 | minor(rdev));
>     }
> The minor device number should be 20-bit. But this operation considers
> minor has only 8-bit and it seems not to correspond to device number
> extension.

I can't figure out why we use dev_to_kdev at all.  I don't remember
where this came from.  I believe the kernel code expects s_logdev to
look like st_rdev, which is what we start with.  Currently,
dev_to_kdev() is basically a no-op anyway.

> Since I didn’t find any information about this aspect in homepage of
> this package, I wonder whether the latest version has completed the
> device number extension? If not, will it be completed in the future?
> And when?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pascal de Bruijn | 12 Jan 2004 11:50
Picon
Favicon

jfs_defrag status

Hi,

The JFS Defrag utility has been on the short term goals list for some 
time now... Is there any timeframe in which a reliable defragger can be 
expected for JFS?

Regards,
Pascal de Bruijn
Permalink | Reply | 0 comments |
headers
Bjoern JACKE | 20 Jan 2004 16:06
Picon
Favicon

character set design problem

Hi,

there has been discussion about charset conversion in JFS once or 
twice before, for example on 
http://www-124.ibm.com/developerworks/bugs/?func=detailbug&bug_id=3387&group_id=35
I want to bring this topic up once more. JFS is the only POSIX 
filesystem which enforces a certain encoding (like the Redmond's 
filesystems do), which makes the iocharset mount option neccessary. 
This mount option however brings up many problems, for example it's 
not possible to use multiple encodings on one filesystem, which is a 
shame for a multiuser os. Even if all people use the same encoding, 
let's say UTF-8, problems come up when there are RPMs or any kind of 
archives which bring files whose names are not validly UTF-8 encoded, 
maybe in latin1 or EUC_JP.
These files can simply not be created on JFS, which leads to 
unforeseeable problems. Even if one would use an encoding like 
iocharset=iso8859-1, which is 8-bit, utf-8 cannot be created because 
not all 255 possible characters are valid in iso8859-1. A nasty 
workaround to get a sane Unix-like filesystem, where all kind of 
filenames can be created (except for slash and null) is to use an 
8-bit encoding like cp850 with iocharset, where all 255 characters are 
defined, and thus also utf-8 and all kinds of byte sequences are 
valid. This will not make the filenames appear correct inside (in 
UTF-16) but it will lead to sane behaviour.
Having to use such a trick to get a sane behaving JFS is not a very 
nice way. Having correct representation of the filenames inside in 
UTF-16 would by the way just make sense it the filesystem is for 
example shared with an OS/2 system.
Wouldn't it make senѕe to just do charset conversion if this is 
explictly wished by the user, for example just if a convert mount
(Continue reading)

Permalink | Reply | 7 comments |
headers
Dave Kleikamp | 20 Jan 2004 16:30
Picon
Favicon

Re: character set design problem

On Tue, 2004-01-20 at 09:06, Bjoern JACKE wrote:
> Hi,
> 
> there has been discussion about charset conversion in JFS once or 
> twice before, for example on 
> http://www-124.ibm.com/developerworks/bugs/?func=detailbug&bug_id=3387&group_id=35
> I want to bring this topic up once more. JFS is the only POSIX 
> filesystem which enforces a certain encoding (like the Redmond's 
> filesystems do), which makes the iocharset mount option neccessary. 
> This mount option however brings up many problems, for example it's 
> not possible to use multiple encodings on one filesystem, which is a 
> shame for a multiuser os. 

This is a shame.  This JFS was designed on OS/2, where it was possible
for the kernel to convert to the user's charset, since the process's
locale was available to the kernel.  JFS has no way of knowing the
process's charset in Linux.

> Even if all people use the same encoding, 
> let's say UTF-8, problems come up when there are RPMs or any kind of 
> archives which bring files whose names are not validly UTF-8 encoded, 
> maybe in latin1 or EUC_JP.
> These files can simply not be created on JFS, which leads to 
> unforeseeable problems. Even if one would use an encoding like 
> iocharset=iso8859-1, which is 8-bit, utf-8 cannot be created because 
> not all 255 possible characters are valid in iso8859-1. 

Actually, I believe that the iso8859-1 charset was fixed in the 2.6
kernel so that all 8-bit characters are represented.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bjoern JACKE | 20 Jan 2004 17:17
Picon
Favicon

Re: character set design problem

On 2004-01-20 at 09:30 -0600 Dave Kleikamp sent off:
>This is a shame.  This JFS was designed on OS/2, where it was possible
>for the kernel to convert to the user's charset, since the process's
>locale was available to the kernel.  JFS has no way of knowing the
>process's charset in Linux.

yes, and that's why I suggest to introduce a "convert" mount option to 
give the possibility to keep JFS converting from $iocharset to UTF-16. 
The default for Linux' JFS however should be to behave like a sane 
Unix filesystem.

>> Even if all people use the same encoding, 
>> let's say UTF-8, problems come up when there are RPMs or any kind of 
>> archives which bring files whose names are not validly UTF-8 encoded, 
>> maybe in latin1 or EUC_JP.
>> These files can simply not be created on JFS, which leads to 
>> unforeseeable problems. Even if one would use an encoding like 
>> iocharset=iso8859-1, which is 8-bit, utf-8 cannot be created because 
>> not all 255 possible characters are valid in iso8859-1. 
>
>Actually, I believe that the iso8859-1 charset was fixed in the 2.6
>kernel so that all 8-bit characters are represented.

what does mean "fixed". In ISO-8859-1 not all 255 characters are 
defined. So the NLS module works correct.

>> A nasty 
>> workaround to get a sane Unix-like filesystem, where all kind of 
>> filenames can be created (except for slash and null) is to use an 
>> 8-bit encoding like cp850 with iocharset, where all 255 characters are
(Continue reading)

Permalink | Reply | 1 comment |
headers
szonyi calin | 20 Jan 2004 17:25
Picon
Favicon

Re: character set design problem

 --- Dave Kleikamp <shaggy <at> austin.ibm.com> a écrit : > On Tue,
2004-01-20 at 09:06, Bjoern JACKE wrote:
> > Hi,
> > 

> > Even if all people use the same encoding, 
> > let's say UTF-8, problems come up when there are RPMs or any
> kind of 
> > archives which bring files whose names are not validly UTF-8
> encoded, 
> > maybe in latin1 or EUC_JP.
> > These files can simply not be created on JFS, which leads to
> 
> > unforeseeable problems. Even if one would use an encoding
> like 
> > iocharset=iso8859-1, which is 8-bit, utf-8 cannot be created
> because 
> > not all 255 possible characters are valid in iso8859-1. 
> 
> Actually, I believe that the iso8859-1 charset was fixed in
> the 2.6
> kernel so that all 8-bit characters are represented.
> 

Sorry for asking
What character set should we use default when we mount a 
jfs filesystem with a 2.6 kernel ?
I use utf8 but sometimes i have the problem described above.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dave Kleikamp | 20 Jan 2004 17:45
Picon
Favicon

Re: character set design problem

On Tue, 2004-01-20 at 10:17, Bjoern JACKE wrote:
> On 2004-01-20 at 09:30 -0600 Dave Kleikamp sent off:
> >This is a shame.  This JFS was designed on OS/2, where it was possible
> >for the kernel to convert to the user's charset, since the process's
> >locale was available to the kernel.  JFS has no way of knowing the
> >process's charset in Linux.
> 
> yes, and that's why I suggest to introduce a "convert" mount option to 
> give the possibility to keep JFS converting from $iocharset to UTF-16. 
> The default for Linux' JFS however should be to behave like a sane 
> Unix filesystem.

If the default was changed to do no conversion, but to store each byte
as a UTF-16 character (which is what iocharset=iso8859-1 now does in
2.6) then the iocharset mount option would be sufficient to indicate
that the conversion is requested.  I see no need for an addition
"convert" option.

> >
> >Actually, I believe that the iso8859-1 charset was fixed in the 2.6
> >kernel so that all 8-bit characters are represented.
> 
> what does mean "fixed". In ISO-8859-1 not all 255 characters are 
> defined. So the NLS module works correct.

"Fixed" in the sense that using it makes JFS behave sanely.  I don't
know whether iso8859-1 should or should not define all 8-bit characters.

> >I believe the new-and-improved iso8859-1 charset provides a good
> >solution.  Is the fix in the 2.6 kernel sufficient, or does someone need
(Continue reading)

Permalink | Reply | 0 comments |

Gmane