headers
Bjoern JACKE | 4 Jun 2004 15:19
Picon
Favicon

Re: Re: kernel 2.6.4: Bug in JFS file system?

Hi Dave,

On 2004-03-24 at 07:45 -0600 Dave Kleikamp sent off:
>After many complaints about characters that were being rejected by jfs,
>and after getting as much feedback as I was able to obtain, I changed
>the default behavior so that no translation is done.  Each byte of the
>file name is now stored in the lower byte of the ucs-16 character. 
>(This is equivalent to iocharset=iso8859-1, which is the default value
>of CONFIG_NLS_DEFAULT.)

at least on SLES9 or SUSE 9.1 (I did not check vanilla kernel) this is not fully true.

If I mounted the jfs partition without iocharset and run this:

#!/usr/bin/perl
for (1..255) {
if ($_<10) { $pre="00"}
elsif ($_<100) { $pre="0"}
else { $pre=""}
open FH,">$pre$_--".chr($_);
close FH;
}

The files are created but are not accessable after that. Mounting with
iocharset=iso8859-1 JFS behaves sane and all the files are created and are
accessable.

Bjoern
Permalink | Reply | 1 comment |
headers
Dave Kleikamp | 4 Jun 2004 16:50
Picon
Favicon

Re: Re: kernel 2.6.4: Bug in JFS file system?

On Fri, 2004-06-04 at 08:19, Bjoern JACKE wrote:
> Hi Dave,
> 
> On 2004-03-24 at 07:45 -0600 Dave Kleikamp sent off:
> >After many complaints about characters that were being rejected by jfs,
> >and after getting as much feedback as I was able to obtain, I changed
> >the default behavior so that no translation is done.  Each byte of the
> >file name is now stored in the lower byte of the ucs-16 character. 
> >(This is equivalent to iocharset=iso8859-1, which is the default value
> >of CONFIG_NLS_DEFAULT.)
> 
> at least on SLES9 or SUSE 9.1 (I did not check vanilla kernel) this is not fully true.

My original patch introduced a bug that has since been fixed.  I don't
believe it made it into SuSE 9.1, but it will be in SLES9.

You can get the patch here:
http://linux.bkbits.net:8080/linux-2.5/cset <at> 408e68856uZdem2NqMehmotmMoug2g

> 
> If I mounted the jfs partition without iocharset and run this:
> 
> #!/usr/bin/perl
> for (1..255) {
> if ($_<10) { $pre="00"}
> elsif ($_<100) { $pre="0"}
> else { $pre=""}
> open FH,">$pre$_--".chr($_);
> close FH;
> }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Köpferl | 5 Jun 2004 01:03
Picon

What about E/A

I just read an old article about the Port from os/2 to linux.

They mentioned that extended attributes do still miss in linux impl.

How about that, now?
Attachment (smime.p7s): application/x-pkcs7-signature, 3175 bytes
Permalink | Reply | 1 comment |
headers
Dave Kleikamp | 7 Jun 2004 21:21
Picon
Favicon

Re: What about E/A

On Fri, 2004-06-04 at 18:03, Robert Köpferl wrote:
> I just read an old article about the Port from os/2 to linux.
> 
> They mentioned that extended attributes do still miss in linux impl.
> 
> How about that, now?

jfs on linux now supports extended attributes.  As linux implements
namespaces for xattrs (user.*, system.*), legacy os/2 eas will show up
as os2.NAME on linux.

jfs currently supports the user.*, system.posix_acl_*, and os2.*
namespaces.  I have a patch for adding the trusted.* and security.*
namespaces if you are interested.
--

-- 
David Kleikamp
IBM Linux Technology Center
Permalink | Reply | 0 comments |
headers
Charles Floyd | 9 Jun 2004 18:17
Favicon

directory access time for jfs vs. ext3

Hi,
	I'm experiencing unexpected latency involving directory access on a jfs
partition.  I have 2 machines with identical copies of data.  One of the
machines has the data on a jfs partition, the other on an ext3
partition.  The jfs machine also has a raid-5 setup. To test the access
time I've been executing the following line in the shell:

time ls | wc -l

The command executes is equal time on both machines for more more recent
data (both written and accessed more recently).  However, for older
data, the command takes considerably longer Here are some sample outputs
I received from the jfs (frontend-0) and ext3 (compute-0-0) machines,
respectively:

[11:13:21 cfloyd <at> frontend-0 2004-01-02]$ time ls -1 | wc -l
  11531

real    0m1.587s
user    0m0.040s
sys     0m0.000s

[11:13:46 cfloyd <at> compute-0-0 2004-01-02]$ time ls -1 | wc -l
  11531

real    0m0.056s
user    0m0.030s
sys     0m0.020s
.
.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Kleikamp | 9 Jun 2004 20:20
Picon
Favicon

Re: directory access time for jfs vs. ext3

On Wed, 2004-06-09 at 11:17, Charles Floyd wrote:
> Hi,
> 	I'm experiencing unexpected latency involving directory access on a jfs
> partition.  I have 2 machines with identical copies of data.  One of the
> machines has the data on a jfs partition, the other on an ext3
> partition.  The jfs machine also has a raid-5 setup. To test the access
> time I've been executing the following line in the shell:
> 
> time ls | wc -l
> 
> The command executes is equal time on both machines for more more recent
> data (both written and accessed more recently).  However, for older
> data, the command takes considerably longer Here are some sample outputs
> I received from the jfs (frontend-0) and ext3 (compute-0-0) machines,
> respectively:
> 
> [11:13:21 cfloyd <at> frontend-0 2004-01-02]$ time ls -1 | wc -l

'ls -l' not only reads the directory, but reads the inode for each entry
in order to get the file-type, size, modification times, etc.

>   11531
>  
> real    0m1.587s
> user    0m0.040s
> sys     0m0.000s
> 
> [11:13:46 cfloyd <at> compute-0-0 2004-01-02]$ time ls -1 | wc -l
>   11531
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hironobu SUZUKI | 10 Jun 2004 02:05

[FYI] File system stress test


Basically I use my file system stress suite for DIY PC hardware test.
Recently, I run this suite for different file systems under Linux.

  http://h2np.net/tools/fs-bench-0.2.tar.gz

This test suite had been run for five file systems, ext2, ext3,
reiserfs, xfs and jfs under Knoppix. See below for more detail of
kernel and hardware information.

Please note that my file system test suite IS NOT a kind of file usage
simulation. This is a stress test for system and this IS NOT a final
conclusion for file system performance test.  But I'm interest in this
results.

17GB partition test ( default setting ) 

     Filesystem    Total(sec)
     ---------------------
     ext2          15145
     ext3          19435
     reiserfs      13583
     xfs           15269
     jfs           20296

4GB partition test ( default setting ) 

    Filesystem    Total(sec)
    -----------------------
    ext2          1968
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yaron Minsky | 11 Jun 2004 18:24
Picon
Gravatar

directory access time for jfs vs. ext3

On Wed, 2004-06-09 at 14:20, Dave Kleikamp wrote:
> On Wed, 2004-06-09 at 11:17, Charles Floyd wrote:
> >
> > [11:13:21 cfloyd <at> frontend-0 2004-01-02]$ time ls -1 | wc -l
>
> 'ls -l' not only reads the directory, but reads the inode for each entry
> in order to get the file-type, size, modification times, etc.

That's actually not -l (the letter l), but rather -1 (the number 1).
i.e., it was listed in single-column mode, to ensure that the number of
lines was equal to the number of files.

Even then, though, the difference in performance seems pretty huge ---
almost two orders of magnitude.  Are 2-second ls times normal for a
large JFS directory?  I thought JFS was supposed to beat ext3 on large
directories in particular.

> >   11531
> >
> > real    0m1.587s
> > user    0m0.040s
> > sys     0m0.000s
> >
> > [11:13:46 cfloyd <at> compute-0-0 2004-01-02]$ time ls -1 | wc -l
> >   11531
> >
> > real    0m0.056s
> > user    0m0.030s
> > sys     0m0.020s
>
(Continue reading)

Permalink | Reply | 501 comments |
headers
Dave Kleikamp | 11 Jun 2004 19:39
Picon
Favicon

Re: directory access time for jfs vs. ext3

On Fri, 2004-06-11 at 11:24, Yaron Minsky wrote:
> On Wed, 2004-06-09 at 14:20, Dave Kleikamp wrote:
> > On Wed, 2004-06-09 at 11:17, Charles Floyd wrote:
> > >
> > > [11:13:21 cfloyd <at> frontend-0 2004-01-02]$ time ls -1 | wc -l
> >
> > 'ls -l' not only reads the directory, but reads the inode for each entry
> > in order to get the file-type, size, modification times, etc.
> 
> That's actually not -l (the letter l), but rather -1 (the number 1).
> i.e., it was listed in single-column mode, to ensure that the number of
> lines was equal to the number of files.

Oops.  It's hard to tell the difference in the font I'm using.  :^)

> Even then, though, the difference in performance seems pretty huge ---
> almost two orders of magnitude.  Are 2-second ls times normal for a
> large JFS directory?  I thought JFS was supposed to beat ext3 on large
> directories in particular.

I'm not sure what the reason for the difference is.  I don't think there
is an expectation that jfs would enumerate a directory faster than ext3,
as you need to read both directories in their entirety.  I would expect
jfs to lookup a particular entry faster than ext3.  Of course,
benchmarking a path lookup may be difficult, because you would have to
make sure the entry was not cached in the dcache. 
--

-- 
David Kleikamp
IBM Linux Technology Center
(Continue reading)

Permalink | Reply | 501 comments |
headers
Yaron Minsky | 12 Jun 2004 00:59
Picon
Gravatar

Re: Re: directory access time for jfs vs. ext3

On Fri, 11 Jun 2004 12:39:34 -0500, Dave Kleikamp <shaggy <at> austin.ibm.com> wrote:
> 
> On Fri, 2004-06-11 at 11:24, Yaron Minsky wrote:
> > On Wed, 2004-06-09 at 14:20, Dave Kleikamp wrote:
> > > On Wed, 2004-06-09 at 11:17, Charles Floyd wrote:
> > > >
> > > > [11:13:21 cfloyd <at> frontend-0 2004-01-02]$ time ls -1 | wc -l
> > >
> > > 'ls -l' not only reads the directory, but reads the inode for each entry
> > > in order to get the file-type, size, modification times, etc.
> >
> > That's actually not -l (the letter l), but rather -1 (the number 1).
> > i.e., it was listed in single-column mode, to ensure that the number of
> > lines was equal to the number of files.
> 
> Oops.  It's hard to tell the difference in the font I'm using.  :^)
> 
> > Even then, though, the difference in performance seems pretty huge ---
> > almost two orders of magnitude.  Are 2-second ls times normal for a
> > large JFS directory?  I thought JFS was supposed to beat ext3 on large
> > directories in particular.
> 
> I'm not sure what the reason for the difference is.  I don't think there
> is an expectation that jfs would enumerate a directory faster than ext3,
> as you need to read both directories in their entirety.  I would expect
> jfs to lookup a particular entry faster than ext3.  Of course,
> benchmarking a path lookup may be difficult, because you would have to
> make sure the entry was not cached in the dcache.

That's fair enough --- you are iterating over the whole thing, so
(Continue reading)

Permalink | Reply | 0 comments |

Gmane