[ANNOUNCE] new reiser4 snapshot released.

[ANNOUNCE] new reiser4 snapshot released.

[Nikita Danilov]

Hello,

new reiser4 snapshot against 2.6.5-rc2 is available at

http://www.namesys.com/snapshots/2004.03.26/

It is mainly bug-fixing release. See READ.ME for the list of fixes and
caveats.

Should no significant problems be found in this snapshot, we shall start
sending patches to -mm next week.

Nikita.

Reiser4 needs more testers

[Hans Reiser]

We have one NFS related bug remaining, and one mmap all of memory 
related bug (and performance issue) that you can hit using iozone.  We 
will fix both of these in next week's snapshot, they were both multi-day 
bug fixes.  When they are fixed, unless users/distros find bugs next 
week we will submit it for inclusion in the -mm and then the official 
kernel.

We hope it is now fairly stable for average users if you avoid those two 
issues (we need to get rid of those dire warnings about its 
stability...., we will remember that next snapshot....;-) )

We need a lot more real user testers, because we have run out of scripts 
that can crash it, and there are distros that would like to ship it 
soon.  Please also complain to vitaly@namesys.com and ramon@namesys.com 
about poor documentation, etc., ....

The new reiser4 snapshot (against 2.6.5-rc2) is available at

http://www.namesys.com/snapshots/2004.03.26/


-- 
Hans

Re: Reiser4 needs more testers

[Dr. Giovanni A. Orlando]

Hans Reiser wrote:

Hi Hans,

    We will test the last snapshot.

Thanks,
Giovanni

> We have one NFS related bug remaining, and one mmap all of memory 
> related bug (and performance issue) that you can hit using iozone.  We 
> will fix both of these in next week's snapshot, they were both 
> multi-day bug fixes.  When they are fixed, unless users/distros find 
> bugs next week we will submit it for inclusion in the -mm and then the 
> official kernel.
>
> We hope it is now fairly stable for average users if you avoid those 
> two issues (we need to get rid of those dire warnings about its 
> stability...., we will remember that next snapshot....;-) )
>
> We need a lot more real user testers, because we have run out of 
> scripts that can crash it, and there are distros that would like to 
> ship it soon.  Please also complain to vitaly@namesys.com and 
> ramon@namesys.com about poor documentation, etc., ....
>
> The new reiser4 snapshot (against 2.6.5-rc2) is available at
>
> http://www.namesys.com/snapshots/2004.03.26/
>
>


-- 

-- 

--
Check FT Websites ... 
http://www.futuretg.com  - ftp://ftp.futuretg.com
http://www.FTLinuxCourse.com
                            /Certification
http://www.rpmparadaise.org
http://GNULinuxUtilities.com
http://www.YourPersonalOperatingSystem.com


--

       Europe:                          USA:
	Future Technologies             Future Technologies
	Viale Grigoletti, 20            1158 26th Street #592
	33170 - Pordenone (PN)          Santa Monica, CA 90403
	Italy.                          USA.

Re: Reiser4 needs more testers

[Redeeman]

On Fri, 2004-03-26 at 18:05, Hans Reiser wrote:
> We have one NFS related bug remaining, and one mmap all of memory 
> related bug (and performance issue) that you can hit using iozone.  We 
> will fix both of these in next week's snapshot, they were both multi-day 
> bug fixes.  When they are fixed, unless users/distros find bugs next 
> week we will submit it for inclusion in the -mm and then the official 
> kernel.
> 
> We hope it is now fairly stable for average users if you avoid those two 
> issues (we need to get rid of those dire warnings about its 
> stability...., we will remember that next snapshot....;-) )
> 
i assume reiser4 will be proper to use for real soon? :>

> We need a lot more real user testers, because we have run out of scripts 
> that can crash it, and there are distros that would like to ship it 
> soon.  Please also complain to vitaly@namesys.com and ramon@namesys.com 
> about poor documentation, etc., ....
> 
> The new reiser4 snapshot (against 2.6.5-rc2) is available at
> 
> http://www.namesys.com/snapshots/2004.03.26/
-- 
Regards, Redeeman
redeeman@metanurb.dk

Re: Reiser4 needs more testers

[markw]

I've run through another test on STP with the latest snapshot against
reiser4 and reiserfs for comparison.  Reiser4 still seems to be lagging
behind reiserfs in our DBT-2 workload (the bigger number is better in
the metric):

          metric  url to test results
          ------  ---------------------------------
reiser4   1208    http://khack.osdl.org/stp/290774/
reiserfs  1819    http://khack.osdl.org/stp/290775/

Mark

On 26 Mar, Hans Reiser wrote:
> We have one NFS related bug remaining, and one mmap all of memory 
> related bug (and performance issue) that you can hit using iozone.  We 
> will fix both of these in next week's snapshot, they were both multi-day 
> bug fixes.  When they are fixed, unless users/distros find bugs next 
> week we will submit it for inclusion in the -mm and then the official 
> kernel.
> 
> We hope it is now fairly stable for average users if you avoid those two 
> issues (we need to get rid of those dire warnings about its 
> stability...., we will remember that next snapshot....;-) )
> 
> We need a lot more real user testers, because we have run out of scripts 
> that can crash it, and there are distros that would like to ship it 
> soon.  Please also complain to vitaly@namesys.com and ramon@namesys.com 
> about poor documentation, etc., ....
> 
> The new reiser4 snapshot (against 2.6.5-rc2) is available at
> 
> http://www.namesys.com/snapshots/2004.03.26/

Re: Reiser4 needs more testers

[Hans Reiser]

This was the parallel fsync benchmark?

Hans

markw@osdl.org wrote:

>I've run through another test on STP with the latest snapshot against
>reiser4 and reiserfs for comparison.  Reiser4 still seems to be lagging
>behind reiserfs in our DBT-2 workload (the bigger number is better in
>the metric):
>
>          metric  url to test results
>          ------  ---------------------------------
>reiser4   1208    http://khack.osdl.org/stp/290774/
>reiserfs  1819    http://khack.osdl.org/stp/290775/
>
>Mark
>
>On 26 Mar, Hans Reiser wrote:
>  
>
>>We have one NFS related bug remaining, and one mmap all of memory 
>>related bug (and performance issue) that you can hit using iozone.  We 
>>will fix both of these in next week's snapshot, they were both multi-day 
>>bug fixes.  When they are fixed, unless users/distros find bugs next 
>>week we will submit it for inclusion in the -mm and then the official 
>>kernel.
>>
>>We hope it is now fairly stable for average users if you avoid those two 
>>issues (we need to get rid of those dire warnings about its 
>>stability...., we will remember that next snapshot....;-) )
>>
>>We need a lot more real user testers, because we have run out of scripts 
>>that can crash it, and there are distros that would like to ship it 
>>soon.  Please also complain to vitaly@namesys.com and ramon@namesys.com 
>>about poor documentation, etc., ....
>>
>>The new reiser4 snapshot (against 2.6.5-rc2) is available at
>>
>>http://www.namesys.com/snapshots/2004.03.26/
>>    
>>
>
>
>
>  
>


-- 
Hans

Re: Reiser4 needs more testers

[markw]

It's an OLTP database workload, but it is the one with all those fsyncs
that Nikita pointed out.

Mark

On 29 Mar, Hans Reiser wrote:
> This was the parallel fsync benchmark?
> 
> Hans
> 
> markw@osdl.org wrote:
> 
>>I've run through another test on STP with the latest snapshot against
>>reiser4 and reiserfs for comparison.  Reiser4 still seems to be lagging
>>behind reiserfs in our DBT-2 workload (the bigger number is better in
>>the metric):
>>
>>          metric  url to test results
>>          ------  ---------------------------------
>>reiser4   1208    http://khack.osdl.org/stp/290774/
>>reiserfs  1819    http://khack.osdl.org/stp/290775/
>>
>>Mark
>>
>>On 26 Mar, Hans Reiser wrote:
>>  
>>
>>>We have one NFS related bug remaining, and one mmap all of memory 
>>>related bug (and performance issue) that you can hit using iozone.  We 
>>>will fix both of these in next week's snapshot, they were both multi-day 
>>>bug fixes.  When they are fixed, unless users/distros find bugs next 
>>>week we will submit it for inclusion in the -mm and then the official 
>>>kernel.
>>>
>>>We hope it is now fairly stable for average users if you avoid those two 
>>>issues (we need to get rid of those dire warnings about its 
>>>stability...., we will remember that next snapshot....;-) )
>>>
>>>We need a lot more real user testers, because we have run out of scripts 
>>>that can crash it, and there are distros that would like to ship it 
>>>soon.  Please also complain to vitaly@namesys.com and ramon@namesys.com 
>>>about poor documentation, etc., ....
>>>
>>>The new reiser4 snapshot (against 2.6.5-rc2) is available at
>>>
>>>http://www.namesys.com/snapshots/2004.03.26/
>>>    
>>>
>>
>>
>>
>>  
>>
> 
> 

Re: Reiser4 needs more testers

[Steven Cole]

On Fri, 2004-03-26 at 10:05, Hans Reiser wrote:
> We have one NFS related bug remaining, [snipped]

Is this the NFS bug you have in mind, or a different one?

I get "Input/output error" when I try to ls the contents of
a directory on an nfs exported reiser4 system from the client system.

spc2 is the nfs server, running kernel 2.6.5-rc2 with latest reiser4 patch.
spc0 is the nfs client, running kernel 2.6.5-rc3-mm1 with nfs-utils 1.0.6.

[steven@spc2 r4_testing]$ df -T
Filesystem    Type   1K-blocks      Used Available Use% Mounted on
/dev/sda1     ext3      798476    156840    601076  21% /
/dev/sda8     ext3     7147260   5570304   1213892  83% /home
none         tmpfs      257456         0    257456   0% /dev/shm
/dev/sda6     ext3     4024188   1874192   1945572  50% /usr
/dev/sda7     ext3      806368    130220    635184  18% /var
/dev/sda9  reiser4     3930680    241556   3689124   7% /r4_testing

[steven@spc2 steven]$ cat /etc/exports
/home/steven/kernels    128.165.67.190(rw)
/r4_testing             128.165.67.190(rw)

[steven@spc2 r4_testing]$ pwd
/r4_testing
[steven@spc2 r4_testing]$ ls
linux-2.6.5-rc2-r4

I lightly tested the reiser4 filesystem by copying the kernel
tree from the /home ext3 system and running one compile.

On the client system, I mounted a few nfs systems:

[steven@spc0 steven]$ df -T
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/hda7     ext3    471M  111M  337M  25% /
/dev/hda11    ext3     26G   15G   11G  59% /home
/dev/hda1     vfat    2.0G  1.9G  135M  94% /mnt/windows
/dev/hda9     ext3    3.9G  1.8G  2.0G  47% /usr
/dev/hda10    ext3    580M  118M  432M  22% /var
/dev/hda5     vfat    1.9G  920M  963M  49% /win_d
/dev/hda6     vfat    1.8G  1.3G  511M  72% /win_e
spc5:/share/from_spc0
               nfs     34G   25G  8.7G  74% /spc5_backup
spc2:/r4_testing
               nfs    3.8G  236M  3.6G   7% /home/steven/r4_testing
spc2:/home/steven/kernels
               nfs    6.9G  5.4G  1.2G  83% /home/steven/spc2_kernels
[steven@spc0 steven]$ uname -r
2.6.5-rc3-mm1

The ext3 system works just fine:

[steven@spc0 steven]$ ls /home/steven/spc2_kernels
2.6.0-test8-mm1   fs/                              linux-2.6.2-r4/       linux-2.6.5-rc2-r4/  r4/
2.6.0-test9-mm1   getit                            linux-2.6.2-rc2-mm1/  patch-2.6.2-rc2      r4.tar.gz
2.6.2-rc2-mm1     kexec-260test8-mm1.patch         linux-2.6.2.tar.bz2   patch-2.6.5-rc2      reiser4/
2.6.4-mm1         kexec-260test9-mm1-update.patch  linux-2.6.4-mm1/      patch-fixk           reiser4.tar.gz
4g4g_kexec.patch  kexec-260test9.patch             linux-2.6.4.tar.bz2   patch-nikita         thediff
all.diff          linux-2.6.1.tar.bz2              linux-2.6.4-vanilla/  patch-nikita2

But the reiser4 system does not:

[steven@spc0 steven]$ ls /home/steven/r4_testing
ls: /home/steven/r4_testing/linux-2.6.5-rc2-r4: Input/output error


Steven

Re: Reiser4 needs more testers

[Hans Reiser]

Yes, it is a readdir related NFS bug.  I should have added that it is 
serious enough to make NFS over reiser4 a bad idea.

Hans

Steven Cole wrote:

>On Fri, 2004-03-26 at 10:05, Hans Reiser wrote:
>  
>
>>We have one NFS related bug remaining, [snipped]
>>    
>>
>
>Is this the NFS bug you have in mind, or a different one?
>
>I get "Input/output error" when I try to ls the contents of
>a directory on an nfs exported reiser4 system from the client system.
>
>spc2 is the nfs server, running kernel 2.6.5-rc2 with latest reiser4 patch.
>spc0 is the nfs client, running kernel 2.6.5-rc3-mm1 with nfs-utils 1.0.6.
>
>[steven@spc2 r4_testing]$ df -T
>Filesystem    Type   1K-blocks      Used Available Use% Mounted on
>/dev/sda1     ext3      798476    156840    601076  21% /
>/dev/sda8     ext3     7147260   5570304   1213892  83% /home
>none         tmpfs      257456         0    257456   0% /dev/shm
>/dev/sda6     ext3     4024188   1874192   1945572  50% /usr
>/dev/sda7     ext3      806368    130220    635184  18% /var
>/dev/sda9  reiser4     3930680    241556   3689124   7% /r4_testing
>
>[steven@spc2 steven]$ cat /etc/exports
>/home/steven/kernels    128.165.67.190(rw)
>/r4_testing             128.165.67.190(rw)
>
>[steven@spc2 r4_testing]$ pwd
>/r4_testing
>[steven@spc2 r4_testing]$ ls
>linux-2.6.5-rc2-r4
>
>I lightly tested the reiser4 filesystem by copying the kernel
>tree from the /home ext3 system and running one compile.
>
>On the client system, I mounted a few nfs systems:
>
>[steven@spc0 steven]$ df -T
>Filesystem    Type    Size  Used Avail Use% Mounted on
>/dev/hda7     ext3    471M  111M  337M  25% /
>/dev/hda11    ext3     26G   15G   11G  59% /home
>/dev/hda1     vfat    2.0G  1.9G  135M  94% /mnt/windows
>/dev/hda9     ext3    3.9G  1.8G  2.0G  47% /usr
>/dev/hda10    ext3    580M  118M  432M  22% /var
>/dev/hda5     vfat    1.9G  920M  963M  49% /win_d
>/dev/hda6     vfat    1.8G  1.3G  511M  72% /win_e
>spc5:/share/from_spc0
>               nfs     34G   25G  8.7G  74% /spc5_backup
>spc2:/r4_testing
>               nfs    3.8G  236M  3.6G   7% /home/steven/r4_testing
>spc2:/home/steven/kernels
>               nfs    6.9G  5.4G  1.2G  83% /home/steven/spc2_kernels
>[steven@spc0 steven]$ uname -r
>2.6.5-rc3-mm1
>
>The ext3 system works just fine:
>
>[steven@spc0 steven]$ ls /home/steven/spc2_kernels
>2.6.0-test8-mm1   fs/                              linux-2.6.2-r4/       linux-2.6.5-rc2-r4/  r4/
>2.6.0-test9-mm1   getit                            linux-2.6.2-rc2-mm1/  patch-2.6.2-rc2      r4.tar.gz
>2.6.2-rc2-mm1     kexec-260test8-mm1.patch         linux-2.6.2.tar.bz2   patch-2.6.5-rc2      reiser4/
>2.6.4-mm1         kexec-260test9-mm1-update.patch  linux-2.6.4-mm1/      patch-fixk           reiser4.tar.gz
>4g4g_kexec.patch  kexec-260test9.patch             linux-2.6.4.tar.bz2   patch-nikita         thediff
>all.diff          linux-2.6.1.tar.bz2              linux-2.6.4-vanilla/  patch-nikita2
>
>But the reiser4 system does not:
>
>[steven@spc0 steven]$ ls /home/steven/r4_testing
>ls: /home/steven/r4_testing/linux-2.6.5-rc2-r4: Input/output error
>
>
>Steven
>
>
>
>
>  
>


-- 
Hans

Re: [ANNOUNCE] new reiser4 snapshot released.

[Jonathan Briggs]

On Fri, 2004-03-26 at 09:45, Nikita Danilov wrote:
> Hello,
> 
> new reiser4 snapshot against 2.6.5-rc2 is available at
> 
> http://www.namesys.com/snapshots/2004.03.26/
> 
> It is mainly bug-fixing release. See READ.ME for the list of fixes and
> caveats.

A definition of fibration:
http://mathworld.wolfram.com/Fibration.html

I'm going to have to study math for about a year before I understand all
that, I think.

It's a good thing we won't have to understand "fiber bundles",
"paracompact topological space" and the "homotopy lifting property" to
USE Reiser4.

*grin*

If I missed the discussion or a web page, I am sorry.  But could someone
post a quick explanation or pointer to one about this fibration plugin? 
What does it do and what effects will it have?

-- 
Jonathan Briggs
jbriggs@esoft.com

Re: [ANNOUNCE] new reiser4 snapshot released.

[Jonathan Briggs]

On Fri, 2004-03-26 at 09:45, Nikita Danilov wrote:
> Hello,
> 
> new reiser4 snapshot against 2.6.5-rc2 is available at
> 
> http://www.namesys.com/snapshots/2004.03.26/
> 
> It is mainly bug-fixing release. See READ.ME for the list of fixes and
> caveats.

A definition of fibration:
http://mathworld.wolfram.com/Fibration.html

I'm going to have to study math for about a year before I understand all
that, I think.

It's a good thing we won't have to understand "fiber bundles",
"paracompact topological space" and the "homotopy lifting property" to
USE Reiser4.

*grin*

If I missed the discussion or a web page, I am sorry.  But could someone
post a quick explanation or pointer to one about this fibration plugin? 
What does it do and what effects will it have?

-- 
Jonathan Briggs
jbriggs@esoft.com

Re: [ANNOUNCE] new reiser4 snapshot released.

[Nikita Danilov]

Jonathan Briggs writes:
 > On Fri, 2004-03-26 at 09:45, Nikita Danilov wrote:
 > > Hello,
 > > 
 > > new reiser4 snapshot against 2.6.5-rc2 is available at
 > > 
 > > http://www.namesys.com/snapshots/2004.03.26/
 > > 
 > > It is mainly bug-fixing release. See READ.ME for the list of fixes and
 > > caveats.
 > 
 > A definition of fibration:
 > http://mathworld.wolfram.com/Fibration.html

Reiser4 plugin was named this was due to some (arguably vague)
similarity with mathematical fibrations.

 > 
 > I'm going to have to study math for about a year before I understand all
 > that, I think.
 > 
 > It's a good thing we won't have to understand "fiber bundles",
 > "paracompact topological space" and the "homotopy lifting property" to
 > USE Reiser4.
 > 
 > *grin*

Why, of course one has to understand it. Reiser4 refuses to mount unless
supplied with the homotopy group of the tangent bundle of hard drive,
for sure.

 > 
 > If I missed the discussion or a web page, I am sorry.  But could someone
 > post a quick explanation or pointer to one about this fibration plugin? 
 > What does it do and what effects will it have?

Fibration plugin affects how disk blocks are allocated for the files
within the same directory. Basically, in reiser4 all file system data
and meta-data (except for allocator bitmaps) are stored in a single
balanced tree. Every piece of information in the file system (byte of
file data, on-disk inode, directory entry containing file name, etc.)
has a key that allows to locate this information in the tree. This
imposes natural order on all file system data (because keys are just
large integers, and can be compared).

Block allocator tries to allocate blocks in a parent-first tree
order. This means, that things with close keys have chances to be close
to each other on a disk. This leads to the main high-level mechanism
that reiser4 uses to control disk layout: through key assignment.

In particular fibration plugin is called when new name is inserted into
a directory, and, based on a name, selects some (otherwise unused) 7 bits
in a key of directory entry. This allows to "slice" directory content
into "fibers", hence the name.

For example, one possible implementation is to place .o files in one
fiber and all others in another. This significantly speeds compilations
up, because .o files are created close to each other and don't interfere
with sources. Fibrations, and well as other plugins, can be set
per-object, see http://www.namesys.com/v4/pseudo.html for details.

 > 
 > -- 
 > Jonathan Briggs
 > jbriggs@esoft.com
 > 

Nikita.

Re: [ANNOUNCE] new reiser4 snapshot released.

[Hans Reiser]

Nikita, would you confirm that the default fibration is to sort all 
files with '.' as the penultimate character by their last character 
first and then by the rest of the name in the usual lexicographic order? 
(If that is not the default, then please make it the default.)

Also, please note that the URL you supplied does not yet describe the 
fibration plugin and its available settings.  Please correct that on Monday.

-- 
Hans

Re: [ANNOUNCE] new reiser4 snapshot released.

[Cyrille Chepelov]

Le Fri, Mar 26, 2004, à 09:11:00AM -0800, Hans Reiser a écrit:

> Nikita, would you confirm that the default fibration is to sort all 
> files with '.' as the penultimate character by their last character 
> first and then by the rest of the name in the usual lexicographic order? 
> (If that is not the default, then please make it the default.)

Wouldn't it be slightly beneficial to expand this policy to not just
look for extensions matching .*\.(?) but .*\.(.*) as well?

	-- Cyrille, needing some time to dive back into reiser4 testing

-- 

Re: [ANNOUNCE] new reiser4 snapshot released.

[Hans Reiser]

Cyrille Chepelov wrote:

>Le Fri, Mar 26, 2004, Ã  09:11:00AM -0800, Hans Reiser a écrit:
>
>  
>
>>Nikita, would you confirm that the default fibration is to sort all 
>>files with '.' as the penultimate character by their last character 
>>first and then by the rest of the name in the usual lexicographic order? 
>>(If that is not the default, then please make it the default.)
>>    
>>
>
>Wouldn't it be slightly beneficial to expand this policy to not just
>look for extensions matching .*\.(?) but .*\.(.*) as well?
>
>	-- Cyrille, needing some time to dive back into reiser4 testing
>
>  
>
I thought about that, but other than compiles I don't know of an 
application that would benefit from this performance wise, and compiles 
usually have . as the penultimate character in their fileset filenames.  
I would actually much like to get feedback from others on this.

-- 
Hans

Re: [ANNOUNCE] new reiser4 snapshot released.

[Cyrille Chepelov]

Le Mon, Mar 29, 2004, à 08:19:56AM -0800, Hans Reiser a écrit:


> >Wouldn't it be slightly beneficial to expand this policy to not just
> >look for extensions matching .*\.(?) but .*\.(.*) as well?

> I thought about that, but other than compiles I don't know of an 
> application that would benefit from this performance wise, and compiles 
> usually have . as the penultimate character in their fileset filenames.  
> I would actually much like to get feedback from others on this.

I see. A little question on the importanceness of solving this right up
front: is it possible to change the fibration policy of a mounted and active
file system? Does such a change affect the repacker (as in: swapping the
fibration policy causes the repacker to start shuffling things around
according to the new policy)? If that's the case, then I guess there's some
wiggle room for imperfection...

(in fact, on second thought, my request wouldn't necessarily cause the best
performance to happen. Norton Defrag used to have a "sort by type" option
ca. 1994, and I remember that on my PC, it didn't give the best
performance). 

Just out of curiosity, is it possible to create a fibration policy based on 
atime/mtime/ctime?

	-- Cyrille

-- 

Re: [ANNOUNCE] new reiser4 snapshot released.

[Vladimir Saveliev]

Hello

On Tue, 2004-03-30 at 09:04, Cyrille Chepelov wrote:
> Le Mon, Mar 29, 2004, Ã  08:19:56AM -0800, Hans Reiser a écrit:
> 
> 
> > >Wouldn't it be slightly beneficial to expand this policy to not just
> > >look for extensions matching .*\.(?) but .*\.(.*) as well?
> 
> > I thought about that, but other than compiles I don't know of an 
> > application that would benefit from this performance wise, and compiles 
> > usually have . as the penultimate character in their fileset filenames.  
> > I would actually much like to get feedback from others on this.
> 
> I see. A little question on the importanceness of solving this right up
> front: is it possible to change the fibration policy of a mounted and active
> file system?

Changing fibration policy applies only to empty directory

>  Does such a change affect the repacker (as in: swapping the
> fibration policy causes the repacker to start shuffling things around
> according to the new policy)? 

repacker does not get affected

> If that's the case, then I guess there's some
> wiggle room for imperfection...
> 
> (in fact, on second thought, my request wouldn't necessarily cause the best
> performance to happen. Norton Defrag used to have a "sort by type" option
> ca. 1994, and I remember that on my PC, it didn't give the best
> performance). 
> 
> Just out of curiosity, is it possible to create a fibration policy based on 
> atime/mtime/ctime?
> 
> 	-- Cyrille

[OT] Re[2]: [ANNOUNCE] new reiser4 snapshot released.

[Maciej Soltysiak]

ND> Why, of course one has to understand it. Reiser4 refuses to mount unless
ND> supplied with the homotopy group of the tangent bundle of hard drive,
ND> for sure.
Oh man! Is reiser4 a part of some alien or future technology? From what I read
and hear it seems so new, fresh and advanced, it seems _obvious_ :-)
this code has been inspired by aliens or time travellers from the
future. Or maybe it's just me being not so knowledgible as reiser4
gurus.

Regards,
Maciej

[ANNOUNCE] new reiser4 snapshot released.

[Svetoslav Slavtchev]

anyone having fixes for reiser3 + data loging & xattr,
the fs_activation patch breaks reiser3  

TIA

best,

svetljo

-- 
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz