pseudo files (Re: V4 status)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
cool, thanks.
That's unfortunately very hard to do if you are using usual system calls
(like readdir(2), or open(2)), because they are tunneled through VFS
that enforces some semantics.
Enforces as in, if I enter the name of a directory, it adds a / to it
before it passes to the filesystem?
I know it doesn't chop off trailing slashes (except in Reiser4, for
obvious reasons).
Or, as this has a serious potential for becoming offtopic, can you point
me to some reading material?
Another problem ("ls seems to know it's a file") is with user level
programs that are sometimes too smart.
Maybe I'll try to fix that. Intelligence seems to be the easiest thing
to remove from a program.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQIVAwUBP86O6gisZLIF6uqOAQKepQ//Vl/JRzKc7NkzWDi1KuIjR6D5/tljQlOD
O3ZYhv42Ugfk3J+HEF61ObeahPUqjpBXiEV9WKKp/m39EmdF3xyO7FvfiUwtwOVG
yLvhz/dE8WaUD4MQPVO/E0qZ+/cVb0qzfuBBdeGrTgfb/2F3oUIkiWjI7ftkpfaZ
spljQljQgO5fyvkaTYsjJ30hEJKBUHcYyMQ101FuSKOpuV0ZSrHIGlYaVC+8TJMl
DKdx0rfkoBAFEtgwkeoigYslBUurfJbscHLNVMIlsI3rhufIJ5sn3OEyl8animI0
XFG6ljDATMnGYYy2g7pat226a2l9skzEsMtcCH/XrWweX17QRCgZdOZSkzKosaXX
paeX4Qn0l64Q4eH4mc5p8Rsx1qWe/pQW8wZouCrgfwaZl2dMxHJtFZNxGVcp+A9/
nHVXRv24mLIQ1jAIMIk+O8so/YQTvFEHbu18BxgTKPNuDsyKPDgr0EguTwHf907w
tGMi931qtaoLuPXSE38/e0et5r9+fOLB9lE+uUNmV6xxFtNh3dMlStbdzuZ8wfYa
cd5sTq9F7Irm7TPxRBd7TTjREEcQYfhyZelmkuZI9eA7aU4WD6RDYziGp87mmevD
NjHzD6D1lKJGX8NW84Nxh/KP8N93LceG6282u9krYxQAY7x47L9AgGsRG/g8zfyw
0+qY2yoVngE=
=bdb/
-END PGP SIGNATURE-
grub (Re: V4 status)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >reiserfs 3.6 works perfect in grub here It may have worked for me, with notail, but I have heard too many stories. Anyway, /boot is 5-10 megs, usually not mounted, so I see no performance loss using ext3 there. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBP86MxgisZLIF6uqOAQLc2xAAgCp7HIDmsWiHW2PHS8aXT/TzzJQjbExP u+xZZNlmOYPZ+Klzj6CTjuWnC16GbG/TqKtAl5jQ0AIGNKoydPpcHGXFhyQCBbPU aan0/WWR1QLV75EIL5x3R5kgO6jI2AHlxcDpRlvKJIdS3Q8iw/KB3L6nO/xqgba4 C0SJg8WPvgGtC/JGOaU8JvIbVeasHogY+HH0HZ6zWuFEckGGjoTiQj7yTDFdCKBg JtsWS7jJ24KdFR0NMOJQTJOOM8z9n9gOIHod5rzP8g7tSprZunJOZsSq8E3pLd5m wSebBC09VYuND6byxyI/HfywVehg+Xx0lbpr6LH3gjp8jg+oR3uO6SoSpsWPEmWP 3B5Ruivlp1EDMWjDIDUjanwroIRR0Yv3efGwORYUFnxQMGNy6HLmazgJ66lsA9Vq e/bMIDflf6Gp86aH+gTlSOVfc/H23gzjWsz6VdpUvYoZe7PxtEipw6Wokx+v1gS1 imR3/qgHkPmltN+RkSNU0+SjTxKQsSuX++DmQ1j3/VW0mARIwdz4UGi+xNzHH7AC HXat5yqlzRJexgYVjXFs+ptdG6aPpoStR3hiTGCTZgAscWxE6pb/vrlCYt+WTQFR w1mVufQVpQ0ZYEsYYw5s8//igMapxmm4JpbCebxyV+sPORBnBDPmKsNBH8639QlG onUku5zQmjY= =p/Gi -END PGP SIGNATURE-
Re: FW: reiser4 plugin for maildir
[reiser4 plugins to make mail delivery faster] There are a few basic things that slow down mail servers when they talk to filesystems: 1) multiple threads delivering to the same directory contend for the directory semaphore for creating new files 2) atomic creation of an entire file 3) high load leads to numerous small synchronous filesystem operations when multiple threads all try to deliver at once. #1 is best fixed at the VFS level, basically allowing more fine grained directory locks (lustre needs this as well I think). It could be dealt with entirely inside reiser4, but this is a generic need for linux as a whole I think. #2 and #3 could be dealt with in a reiser4 transaction subsystem. Basically the mail server would deliver a number of messages and trigger commits at regular intervals, and reiser4 would make sure the files were created atomically in the FS. The mail server would not report the file as delivered to the smtp client until the commit had completed. So, I definitely think you could use reiser4 to gain significant mail delivery performance. But you probably don't need a specific plugin outside the transaction subsystems. The obvious benefit of only using the transaction systems is that you won't need to teach mail clients about the reiser4 plugin. There's lots of other plugin topics related to teaching the FS about various file formats. This may or may not be a good idea in some cases, but it is a good place for research. I'd start by looking at the xattr interfaces and Hans' ideas for FS-as-a-database. -chris
FW: reiser4 plugin for maildir
-Original Message- From: Burnes, James Sent: Wednesday, December 03, 2003 1:38 PM To: 'Hans Reiser' Subject: RE: reiser4 plugin for maildir > >I was considering installing qmail recently and upon analyzing the > >architecture of their queue structure it looked like Dan Bernstein > expended > >a lot of effort to achieve efficiency when you have 'many files in the > same > >directory'. > > > >All the while I was thinking that Hans Reiser has already solved this > >problem in reiserfs. > > > >Has anyone written a reiser4 plugin for qmail that implements this > queueing > >structure directly in the file system? > > > > > No, and I'd love to see it happen. Ok. At least I'm on the right track. I was re-reading the reiser4 docs yesterday and specifically the methods that need to be implemented for each reiser4 plugin/object type. All very elegant, but what wasn't too clear was the interface between the new apps that can take advantage of these pluggable objects directly and the interface between old-style POSIX apps and reiser4 that just want to see these objects as files. Since I just joined the reiserfs list, I'll copy/move this discussion there. I'm sure there are a lot of people thinking about just these types of issues. That way we can efficiently offload your brain, Hans ;-) Some use-cases: (man haven't done some of this for a while...) 1. Web application in PHP or something acting as an OGG or MP3 store, archives and reads audio files. There is obvious structure in these files and it seems silly to keep opening and reparsing their contents to extract various bits of header information or separate forks in the data. The web app understands this and R/W's the MP3 file using reiser4 into its constituent components via the MP3 reiser4 plugin. All interaction between the app and the MP3 object lives at this layer of OO abstraction. Meanwhile the host system's backup procedure uses POSIX fopens or whatever to backup and restore the MP3 files. Does the plugin have to know how to serially marshall and unmarshall the object for POSIX programs so that it appears as a 'normal' MP3 file? 2. Someone develops a new mod_dav (mod_reiserDAV?) for Apache, that uses a special reiser4 plugin to implement all of the DAV structures in reiser4 instead of the current hack that uses a DBM database. Interesting/cool features of DAV such as ordered DAV containers and revision control are implemented directly with the reiser4 plugin. 3. As mentioned before, Dan Berstein's qmail program goes through a *lot* of gyrations to efficiently implement many files in one directory (as well as other issues). I haven't tried a qmail queue on reiser3, but I gather that they end up fighting each other to achieve the same goals. Rather than qmail trying to simulate a better file system, why not hack it to implement message queuing functions in a reiser4 plugin. Anyway, I'm just a beginner at kernel level filesystems, but I do have about 20 years systems software background so maybe I should give it a go. It's not going to get done tomorrow, but it should be fun. All I have to loose is my test partition ;-) jim burnes security engineer great-west, denver
Re: V4 status
Hans Reiser writes:
> David Masover wrote:
>
> >
> >
> > The only thing I might complain about is that, although it was listed
> > as a possibility to display file permissions as files within a file
> > (for example, I should be able to do 'touch file; ls file'), I have
> > had two problems there. First, ls seems to know it's a file, and so I
> > can't see any files within it. Second, it needs the executable bit,
> > or I get permission denied errors when trying to look at any files
> > inside it. Third, even with ls not working, no guesses I've made on
> > potential filenames has worked.
$ chmod u+x foo
$ cat foo/..pseudo
or, take a look at http://namesys.com/v4/pseudo.html
>
> Nikita will comment on the state of this code, and your remarks below.
>
> >
> > I know almost nothing about the interface behind this. That said,
> > here's what I'd suggest (without knowing any better):
> > - - If I look at something without using a trailing slash, it should
> > be treated as a file, except maybe for compatibility reasons.
> > - - If I do use a trailing slash, or as a parent directory to
> > anything, it should be treated as a directory.
> > - - If it is a regular file (and not a directory pretending to be a
> > file through some odd plugin -- /etc/passwd could be a file
> > constructed from files in /etc/passwd/) then permission to view it as
> > a directory should be assumed for anyone with read access. As an
> > alternative, the ability to change into a directory could be
> > implemented as another security attribute, which is automatically
> > linked to executable permission for "normal" directories.
> >
That's unfortunately very hard to do if you are using usual system calls
(like readdir(2), or open(2)), because they are tunneled through VFS
that enforces some semantics.
Another problem ("ls seems to know it's a file") is with user level
programs that are sometimes too smart.
> >
> >
> >
>
>
> --
> Hans
>
>
Nikita.
Re: V4 status
David Masover wrote: The only thing I might complain about is that, although it was listed as a possibility to display file permissions as files within a file (for example, I should be able to do 'touch file; ls file'), I have had two problems there. First, ls seems to know it's a file, and so I can't see any files within it. Second, it needs the executable bit, or I get permission denied errors when trying to look at any files inside it. Third, even with ls not working, no guesses I've made on potential filenames has worked. Nikita will comment on the state of this code, and your remarks below. I know almost nothing about the interface behind this. That said, here's what I'd suggest (without knowing any better): - - If I look at something without using a trailing slash, it should be treated as a file, except maybe for compatibility reasons. - - If I do use a trailing slash, or as a parent directory to anything, it should be treated as a directory. - - If it is a regular file (and not a directory pretending to be a file through some odd plugin -- /etc/passwd could be a file constructed from files in /etc/passwd/) then permission to view it as a directory should be assumed for anyone with read access. As an alternative, the ability to change into a directory could be implemented as another security attribute, which is automatically linked to executable permission for "normal" directories. -- Hans
Re: V4 status
We are still able to crash reiser4. It has been 1 month from being debugged for a very long time now Sigh. Vs is working on nfs file handle encoding and decoding. We need to release a snapshot again sometime reasonably soon Hans David Masover wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fredrik Tolf wrote: May I ask what the current stability status is for V4? Is there mayhap a HTTP resource for it that I have not found? Fredrik Tolf I believe patching your kernel will not hurt anything else, and mounting a filesystem will probably not hurt anything else. I have a laptop on which I use Reiser4 for everything but /boot (as v4 is not supported by grub and v3 was never supported very well). It seems reasonably stable (once I fixed a problem with xscreensaver). However, I still back up daily, and will continue to do so until someone here tells me I can trust it. (Then I'll fall back to no backup until I get the tape drive working so I can do proper incremental backups.) BTW, to all -- I have had no problems specifically reiser4 related. I was complaining of crashes earlier, but it seems those were either in my pam libs or my screensaver -- reinstalling all my software seemed to help (and as I didn't touch the kernel, it wouldn't have fixed it if it were a filesystem issue). In fact, I know for sure it's at least partly due to problems with pam and related things, because my su (among other things) had lost its setuid bit -- due to my using the wrong arguments to cp when upgrading from v3. The only thing I might complain about is that, although it was listed as a possibility to display file permissions as files within a file (for example, I should be able to do 'touch file; ls file'), I have had two problems there. First, ls seems to know it's a file, and so I can't see any files within it. Second, it needs the executable bit, or I get permission denied errors when trying to look at any files inside it. Third, even with ls not working, no guesses I've made on potential filenames has worked. I know almost nothing about the interface behind this. That said, here's what I'd suggest (without knowing any better): - - If I look at something without using a trailing slash, it should be treated as a file, except maybe for compatibility reasons. - - If I do use a trailing slash, or as a parent directory to anything, it should be treated as a directory. - - If it is a regular file (and not a directory pretending to be a file through some odd plugin -- /etc/passwd could be a file constructed from files in /etc/passwd/) then permission to view it as a directory should be assumed for anyone with read access. As an alternative, the ability to change into a directory could be implemented as another security attribute, which is automatically linked to executable permission for "normal" directories. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBP81HyAisZLIF6uqOAQIH9w/9HV/r2hZOGiUKUZjDsToFkNr+HJn+fTsj C1imfdKC+tiL9kcI8wfjERFcwj/v6gMCmzXSs/XNRa12cs9Ddm+goeqHhfnjUiO8 FM0y6m7kebonM957VqJvVhxLfJkZvHjn3aCtHxl3oHfme9Xz7FrZbBpTbDTPA+aY wYFFun51dQeIG6P4DqWNUIdEC9UNczdtk+Mhh9QsA9wCcT4bmO3UmiOs0mKN9o6K KXsIJCE0DddXxKhROd0RnSY/jKz3KmpTtsNQDekXPaIvMa01qIQOvqv7bbQ/tux8 OZfYGb8dfR/8TmEIOg7HnrF5agcygpIe2EYb7bwmNi+iT8jA5l4NAOT5EdtzFZxk +5hnX3vrSQezoRmr6cYnxgjZtlR5U/tcCZGLcPtvyL5KnxLE83uDBePfQZI8oXd2 mb4wcrLgmyw02n/m8yE7WMB5ukrj4YKNMIGxLR5u0nuNKJFHFLbqiIshg5ZQY1DF CkWMHF1H18Qv6f6zszec4m47hkt/PKpSEArLzMoFA9ag/WtoNrDQq7+iRxy2LYKH evK5AIMFAL9v3huxmCphHK6bjQzdTsl4mvnsPjB0hHcp+MhIsyBzobhd27oaBcsv Hfj/0RywUwRlRj5zdwuoLuPHYlf38PjZlrAmfENWW2CrOL5+7RgbTGeUe+JU/J+t +KlqxdjP1Dc= =ExXE -END PGP SIGNATURE- -- Hans
Re: Carrying Attributes too Far
Oops, found this in my drafts box after a long time had passed. Hans [EMAIL PROTECTED] wrote: Sorry for the delay in replying. Quoting Hubert Chan <[EMAIL PROTECTED]>: "Leo" == lrc1 <[EMAIL PROTECTED]> writes: [...] Why? Not at all, I would say. Leo> Short answer: because otherwise you have ""attributes" that cannot Leo> interact with files in all the same ways that files can interact Leo> with files" ( http://www.namesys.com/v4/v4.html ). Hard linking isn't a universal attribute, though. For example, you cannot hard link over different filesystems. If an attribute (such as uid, premissions, etc.) are implemented by just taking the file's standard stat data and exposing it as a file interface, that it is similar to that data being from a different filesystem, and so you can't hardlink. This would be similar, I suppose, to if a plugin exposes an MP3's id3 data as files -- it would make no sense to be able to hardlink that, since the data is stored in the MP3 file, and not as part of the filesystem. Yes, it is impossible to hard-link between two files on different volumes (except at mount points) in the Unix filesystem, but it shouldn't be. (More generally, with the necessary permissions it should be possible to make any file the child of any directory via a hard link, except where doing so would create a cycle.) This implies that two filesystems can share an identification number between them. There's no semantic reason why it shouldn't be possible; in other words, if it's meaningful for a file to be named both /pub/pictures/sunrise and /home/alice/pictures/daylight , why would it in fact not be meaningful just because a volume is mounted at /home ? Hard-linking across mount subtrees is not possible in existing Unix filesystems for non-semantic reasons, the most interesting of which is that it doesn't fit with the Unix concept of mount subtrees and mount points. The correct solution to this is to throw out that concept, something I'll post about later. Note that hard-linking between files on different volumes is a necessity if you want to do the kind of things discussed in Future Vision cleanly. If I did a simple search for all mp3s at least 3 minutes long, I would expect to get back a directory which had as its children all the 3-min.+ mp3s visible to me on the computer. I wouldn't necessarily care if some of the mp3s were on a different mount subtree to the search directory, and I wouldn't expect to find things like symlinks being used to duct-tape the mp3s onto the directory. (As to your id3 example: Yes, the id3 file data is stored in the mp3 file, but then the /etc/motd file data is stored in the file /dev/hda1 or whatever. There's no reason why it makes any less sense be able to hard-link to the id3 file than to /etc/motd. Why shouldn't I be able to use a search to get a directory linked to all the id3 files on the system?) But for the sake of argument, let's assume that indeed it should remain impossible to hard-link across mount subtrees, or at least that it will. Will this actually prevent the problems of ordinary directories hard-linking to attribute files not their own? Consider a case in which /pub/somedir and /home/alice/hello.mp3 are both on the same volume, say /dev/hda1 . If even one of hello.mp3's attribute files (or to be more precise, one of the files which inherit metadata from hello.mp3) is on the same mount subtree as somedir , then the restriction on hard-linking between files on different volumes is not sufficient to prevent the problems. So can we find an attribute file of hello.mp3 which might actually be on /dev/hda1 ? An id3 file derived automatically from hello.mp3 should be quite safe; its device file is hello.mp3 , just as hello.mp3 's device file is /dev/hda1 , so it should be in a different mount subtree to hello.mp3 . (But incidentally, this raises another question: if one of hello.mp3 's descendants is a mount point, what happens when alice types mv hello.mp3 hi.mp3 ?) By contrast, imagine that alice writes a short text file of information about hello.mp3. Clearly this is hello.mp3 metadata, so she saves the file in hello.mp3/+/info . info isn't automatically derived from mp3, so why wouldn't it just be another file on /dev/hda1 like hello.mp3 and somedir ? As to permissions, wasn't it the intention to use permissions files as a *replacement* for stat and friends, not just as a means of exposing stat through a file interface? If hello.mp3/+/permissions replaces stat and friends, then it's in the same position as hello.mp3/+/info . If it simply exposes then, then subfile metadata is a lot less interesting - for one thing, it doesn't make implementing different permissions systems any easier (the opposite, in fact). But even if ordinary directories can't hard-link to other files' attribute files, the problem of multiple inheritance of metadata still isn't fully solved. What if two children of hello.mp3/+/ have differe
Re: Strange errors with 2.4.22 patches (from Chris) and bonnie++
On Tue, 2003-12-02 at 03:35, Jens Benecke wrote: > Chris Mason wrote: > > > On Fri, 2003-11-28 at 16:38, Jens Benecke wrote: > > > >> b) bonnie++ on a (previously created) reiserfs partition (with > >>mkreiserfs 3.6.6) exited with random "disk full" errors, although > >>the disk was never full. This didn't happen before. > >> (...) > >> I would appreciate any help. Thank you! :-) > > > > Ugh, the new block allocator isn't properly forcing a commit when an > > allocation fails, so we don't reclaim blocks deleted in an uncommitted > > transaction. I thought this fix got pulled out of the suse kernel when > > namesys and I pulled out the important bug fixes, but it got missed. > > > > porting. > > Hi Chris, > > so... the worst-case impact on this bug is that reiserfs will report "disk > full" when you still have some space available. Right? No data loss, > corruption, or similar Bad Things(tm)? > Correct. I'll have a fix available today along with a remerge of data logging and quota against 2.4.23. > I have two servers here that are supposed to be deployed next week and use > ReiserFS. I've had some bad issues with MySQL files becoming corrupted > after a crash in the past so I'd really like to put these into production > with data-logging patches. > > btw, what are the patches that SuSE uses? IIRC, SuSE ships with data-logging > enabled, right? > SUSE ships data logging and the xattr patches, along with a few others. -chris
Specification for ReiserFS4
Hello, I am interesting in numbers similar to posted in http://www.namesys.com/faq.html There are various characteristic figures for max values for ReiserFS 3.5 and 3.6. I cannot find such spec for ReiserFS4. Can someone help ? Regards, Cyril
Re: V4 status
On Wed, 2003-12-03 at 03:17, David Masover wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Fredrik Tolf wrote: > > >May I ask what the current stability status is for V4? Is there mayhap > >a HTTP resource for it that I have not found? > > > >Fredrik Tolf > > > > > > > > I believe patching your kernel will not hurt anything else, and mounting > a filesystem will probably not hurt anything else. > > I have a laptop on which I use Reiser4 for everything but /boot (as v4 > is not supported by grub and v3 was never supported very well). It reiserfs 3.6 works perfect in grub here > seems reasonably stable (once I fixed a problem with xscreensaver). > However, I still back up daily, and will continue to do so until someone > here tells me I can trust it. (Then I'll fall back to no backup until I > get the tape drive working so I can do proper incremental backups.) > > BTW, to all -- I have had no problems specifically reiser4 related. I > was complaining of crashes earlier, but it seems those were either in my > pam libs or my screensaver -- reinstalling all my software seemed to > help (and as I didn't touch the kernel, it wouldn't have fixed it if it > were a filesystem issue). In fact, I know for sure it's at least partly > due to problems with pam and related things, because my su (among other > things) had lost its setuid bit -- due to my using the wrong arguments > to cp when upgrading from v3. > > The only thing I might complain about is that, although it was listed as > a possibility to display file permissions as files within a file (for > example, I should be able to do 'touch file; ls file'), I have had two > problems there. First, ls seems to know it's a file, and so I can't see > any files within it. Second, it needs the executable bit, or I get > permission denied errors when trying to look at any files inside it. > Third, even with ls not working, no guesses I've made on potential > filenames has worked. > > I know almost nothing about the interface behind this. That said, > here's what I'd suggest (without knowing any better): > - - If I look at something without using a trailing slash, it should be > treated as a file, except maybe for compatibility reasons. > - - If I do use a trailing slash, or as a parent directory to anything, it > should be treated as a directory. > - - If it is a regular file (and not a directory pretending to be a file > through some odd plugin -- /etc/passwd could be a file constructed from > files in /etc/passwd/) then permission to view it as a directory should > be assumed for anyone with read access. As an alternative, the ability > to change into a directory could be implemented as another security > attribute, which is automatically linked to executable permission for > "normal" directories. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.3 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iQIVAwUBP81HyAisZLIF6uqOAQIH9w/9HV/r2hZOGiUKUZjDsToFkNr+HJn+fTsj > C1imfdKC+tiL9kcI8wfjERFcwj/v6gMCmzXSs/XNRa12cs9Ddm+goeqHhfnjUiO8 > FM0y6m7kebonM957VqJvVhxLfJkZvHjn3aCtHxl3oHfme9Xz7FrZbBpTbDTPA+aY > wYFFun51dQeIG6P4DqWNUIdEC9UNczdtk+Mhh9QsA9wCcT4bmO3UmiOs0mKN9o6K > KXsIJCE0DddXxKhROd0RnSY/jKz3KmpTtsNQDekXPaIvMa01qIQOvqv7bbQ/tux8 > OZfYGb8dfR/8TmEIOg7HnrF5agcygpIe2EYb7bwmNi+iT8jA5l4NAOT5EdtzFZxk > +5hnX3vrSQezoRmr6cYnxgjZtlR5U/tcCZGLcPtvyL5KnxLE83uDBePfQZI8oXd2 > mb4wcrLgmyw02n/m8yE7WMB5ukrj4YKNMIGxLR5u0nuNKJFHFLbqiIshg5ZQY1DF > CkWMHF1H18Qv6f6zszec4m47hkt/PKpSEArLzMoFA9ag/WtoNrDQq7+iRxy2LYKH > evK5AIMFAL9v3huxmCphHK6bjQzdTsl4mvnsPjB0hHcp+MhIsyBzobhd27oaBcsv > Hfj/0RywUwRlRj5zdwuoLuPHYlf38PjZlrAmfENWW2CrOL5+7RgbTGeUe+JU/J+t > +KlqxdjP1Dc= > =ExXE > -END PGP SIGNATURE- -- Regards, Redeeman () ascii ribbon campaign - against html e-mail /\- against microsoft attachments
Status data loggin patches?
Hi! Can someone please explain the status of the data logging patch? It should be included in 2.4.23, but it is not there. Was it not sent or was it rejected? Are there versions for 2.6 to test? I would like to test the new kernel, but not without data logging patch. Thanks for your great work! Stephan, using reiserfs since 2.2 -- | Stephan Seitz E-Mail: [EMAIL PROTECTED] | | WWW: http://fsing.fs.uni-sb.de/~stse/| | PGP Public Keys: http://fsing.fs.uni-sb.de/~stse/pgp.html | pgp0.pgp Description: PGP signature
