Prakash Punnoor wrote:
>
>. But nevertheless it didn't survive, as like V3, with time V4 became
>slower and slower. In this case no year was needed, but just one month or
>alike. So end of test...but in fact I'll give V4 another go in the near future.
>
>
Interesting that it got slower with time
What happens when the ext3 inode tables get hit by sector damage? Like
us, ext3 has data munging if you hit the wrong thing, its just that our
sources of data munging are different in the details. Details matter
though, and so we are improving with each release, and V4 does have some
real improvem
Andrew asked me to put together a list of things that need to be done
before merging:
* VFS will dispatch directly to the method of the plugin for the
*_operations methods. This requires duplicating to all plugin methods
the common code currently used by all reiser4 plugins for a given
metho
Theodore Ts'o wrote:
>On Mon, Jun 27, 2005 at 03:18:30PM -0500, Steve Lord wrote:
>
>
>>I presume Ted is referring to problems guaranteeing the integrity of
>>the journal at recovery time. I am coming into this without all the
>>available context, so I may be barking up the wrong tree In
>>p
Artem B. Bityuckiy wrote:
> Vladimir Saveliev wrote:
>
>> I think from the beginning HASHED_DIR_PLUGIN_ID was not supposed to be
>> seekable. It changed later, HASHED_DIR_PLUGIN_ID became both seekable
>> and default in reiser4.
>
> Well, this what I suspected... Would be nice to rename the plugin
Steve, there is a remark about XFS below which you are going to be more
expert on.
Theodore Ts'o wrote:
>Most Linux users are using PC-class hardware. And Ted's First Law of
>PC-Class Hardware is: "Most of it is crap". And then there's Ted's
>Second Law, "Too many system administrators don't do
Artem B. Bityuckiy wrote:
>> Location within a directory in reiser4 is logical number of entry within
>> the directory.
>
> Yes, I know. It does not absolutely correctly handle the way when
> dirents were deleted before and after the saved position.
>
> Well, Nikita kindly answered my questions in
[EMAIL PROTECTED] wrote:
>>tarball/zipfile. Nobody ever suggested that you would actually want to.
>>
>>
> Besides, your point was that you could not run make inside of a kernel
>
Umm, try it when we have it working, on a 1-4GB RAM machine it might not
be so bad. We have the compression
David Masover wrote:
> Hans Reiser wrote:
>
> >David Masover wrote:
>
>
> >>[EMAIL PROTECTED] wrote:
> >>
> >>
> >>>On Sun, 26 Jun 2005 14:58:07 CDT, David Masover said:
> >>
> >>
> >>>>"Plugins&qu
David Masover wrote:
> [EMAIL PROTECTED] wrote:
>
> >On Sun, 26 Jun 2005 14:58:07 CDT, David Masover said:
>
>
> >>"Plugins" is a bad word. This user's combination of plugins is most
> >>likely identical to other users', it's just which ones are enabled, and
> >>which aren't? If they are all inc
Christoph Hellwig wrote:
>On Wed, Jun 22, 2005 at 08:39:01PM -0700, Hans Reiser wrote:
>
>
>>Correct me if I am wrong:
>>
>>What exists currently in VFS are vector instances, not classes. Plugins,
>>selected by pluginids, are vector classes, with each plugini
[EMAIL PROTECTED] wrote:
> (Hint - work out how long a kernel 'make' would take
>if you were doing it inside a .tar.bz2).
>
>
After the first time, not very long, if you had enough ram the
plugin would keep the data uncompressed until it flushed it to disk.
Performance might even improve s
Reuben Farrelly wrote:
> Hi Hans,
>
> On 25/06/2005 12:38 a.m., Hans Reiser wrote:
>
>> fsck is better in V4 than it is in V3. Users should move from V3 to V4,
>> as V3 is obsolete. I agree on that Ted.
>
>
> Perhaps before moving to V4, reiser4progs-1.04 (the mos
Think of reiser4 as being designed to be 90% library routines, and 10%
program. Now, can these libraries be used by other filesystems? Why
yes, some can. How many of them should be used by other filesystems?
Reality: few people are going to rewrite their existing filesytems to
mostly use our
Christian Trefzer wrote:
> Hubert Chan schrieb:
>
>> How about something of the form "nikita-955(file:line)"? Or the
>> reverse: "file:line(nikita-955)". Would that keep everyone happy?
>>
Makes me happy.
Theodore Ts'o wrote:
>On Sat, Jun 25, 2005 at 12:23:41PM -0700, Hans Reiser wrote:
>
>
>>>> assert("trace_hash-89", is_hashed(foo) != 0);
>>>>
>>>>
>>>>
>>Lots of people like corporate anonymity. Some d
[EMAIL PROTECTED] wrote:
> Hmm.. let's see.. I said Reiser isn't in because it shouldn't be
> screwing with
>
>the VFS, and said stuff should be done separate from the Reiser4 filesystem.
>
>
We don't touch a line of VFS code. We look like a normal fs at the
interface.
Shall we send in a file
Pekka Enberg wrote:
>
>
>On Thu, 2005-06-23 at 21:32 +0200, Jens Axboe wrote:
>
>
>>That said, I don't like the reiser name-number style. If you must do
>>something like this, mark responsibility by using a named identifier
>>covering the layer in question instead.
>>
>>assert("trace_has
David Masover wrote:
> The social traditions aren't uniform. In fact, if we're referring to
> all of open source, go hang out on irc.freenode.net#gentoo for a great
> community, whether or not you like the distro. If you want developers,
> there's not too many RTFM's and "I was coding bytecode e
Jeff Garzik wrote:
>
> I've already listed two rather large technical reasons.
They are?
Jeff Garzik wrote:
> Then why not listen to authorities, all of whom are saying "it's not
> ready yet"
What exactly is not ready Jeff? As I see it, this thread is 95%
posturing, and almost no technical reasons for not merging. These
"authorities"seem perfectly content with echoing the words of
[EMAIL PROTECTED] wrote:
> Right - once the VFS hands the call off to reiser4, you're on your own
>
>as far as I'm concerned..
>
>
Well, that is all I ask for, and Christophe and company disagree.
Happy to abstract it more into VFS after the merge if others want it
though
fsck is better in V4 than it is in V3. Users should move from V3 to V4,
as V3 is obsolete. I agree on that Ted.
I also agree that Ted did a great job with fsck.ext*.
V3 was where we learned. There are performance problems in V3 that I
could only fix by writing V4. The balancing code for V3 was ex
David Masover wrote:
>
>
> I was able to recover from bad blocks, though of course no Reiser that I
> know of has had bad block relocation built in...
there was a patch somewhere. Vitaly, please comment.
Alan Cox wrote:
>Thats a good sign. reiser3 was very fragile when blocks of disk went for
>a walk. If you got most of your data back thats a positive sign, not
>statistically a valid sample but a positive sign
>
>
Alan, this is FUD. Our V3 fsck was written after everything else was,
for lack o
Al Viro wrote:
>On Fri, Jun 24, 2005 at 02:03:33AM -0700, Hans Reiser wrote:
>
>
>>Al Viro wrote:
>>
>>
>>
>>>Have I missed the posting with analysis of changes in locking scheme
>>>and update of proof of correctness? If so, please gi
Al Viro wrote:
>Have I missed the posting with analysis of changes in locking scheme
>and update of proof of correctness? If so, please give the message ID.
>
>_That_ had been the major showstopper for any merges, IIRC.
>
>
Ah, the prince of helpfulness has arrived.
Yes, as I remember, last ti
Lincoln Dale wrote:
>
>> Now, if his target is reduced to whether we can eliminate a function
>> indirection, and whether we can review the code together and see if it
>> is easy to extend plugins and pluginids to other filesystems by finding
>> places to make it more generic and accepting of per
Lincoln Dale wrote:
>
> the irony of this whole thread is that history is repeating itself.
> see http://www.ussg.iu.edu/hypermail/linux/kernel/0112.1/0519.html
> kernel developers pushed back on you 3 years ago - in 2001 - what has
> really changed?
It is exactly the same, but rather than dwell
Nikita, I respectfully disagree with what you say about the state of our
atomicity code. It is not so far away as you describe, and probably 6
man weeks work could polish it off. You don't see the value in what I
define as useful, namely atomicity without isolation. Since you don't
see that, it
Alan Cox wrote:
>>I am entitled to get some advantage from being the first on the block
>>
>>
>
>You were not first on the block. Linus was,
>
>thats why it's Linux (well
>not directly his fault about the name) and why he sets policy. I've
>never heard Linus espousing such an idea so I wonder
Alan Cox wrote:
> SMP scaling.
Reiser4 should do much better at this, as it was designed for it. I
wish we had a nice hunking multiprocessor to verify that and work
through the inevitable unintended sources of bottlenecks though.
>
>
>>You know how many I've had thrashed on Reiser4? Two. Th
David Masover wrote:
>
>
> But, there are some things Reiser does better and faster than ext3, even
> if you don't count file-as-directory and other toys. There's nothing
> ext3 does better than Reiser, unless you count the compatibility with
> random bootloaders and low-level tools.
In fairness
One, you were using V3 not V4.
Two, this bug you mention is probably not an fs bug. rm first creates a
list of names, and then removes them.
[EMAIL PROTECTED]:~/scratch> touch fufu
[EMAIL PROTECTED]:~/scratch> touch fifu
[EMAIL PROTECTED]:~/scratch> rm *fu fi*
rm: cannot remove `fifu': No such
Jeff Mahoney wrote:
>All the assertions (a quick grep through the code shows something like
>3800 of them) ultimately result in a reiser4_panic, which BUG()'s. Are
>*all* of these assertions really worth taking the system down? I think a
>reiser4_error function that can abort just that filesystem
Jeff Mahoney wrote:
>Pekka Enberg wrote:
>
>
>>>--- /dev/null2003-09-23 21:59:22.0 +0400
>>>+++ linux-2.6.11-vs/fs/reiser4/pool.c2005-06-03 17:49:38.668204642
>>>+0400
>>>+/* initialise new pool */
>>>+reiser4_internal void
>>>+reiser4_init_pool(reiser4_pool * pool /* po
This is a very nice description, thank you Christophe. My comments are
below.
Christophe Saout wrote:
>Am Dienstag, den 21.06.2005, 18:18 -0700 schrieb Andrew Morton:
>
>
>
>>>What is wrong with having an encryption plugin implemented in this
>>> manner? What is wrong with being able to have
Vladimir Saveliev wrote:
>
>
+/*
+ * Initialization stages for reiser4.
+ *
+ * These enumerate various things that have to be done during reiser4
+ * startup. Initialization code (init_reiser4()) keeps track of what stage
was
+ * reached, so that proper undo can be
David Masover wrote:
> Nikita Danilov wrote:
>
> >David Masover writes:
>
> >[...]
>
> > >
> > > What we want is to have programs that can write small changes to one
> > > file or to many files, lump all those changes into a transaction, and
> > > have the transaction either succeed or fail.
>
> >
Since this did not get an answer, and since it is the technical email in
the flamefest, I thought I would resend it appropriately labeled.
Correct me if I am wrong:
What exists currently in VFS are vector instances, not classes. Plugins,
selected by pluginids, are vector classes, with each plugin
Pekka J Enberg wrote:
> Hi Hans,
> On Thu, 2005-06-23 at 00:42 -0700, Hans Reiser wrote:
>
>> > These assertion codes are meaningless to the rest of us so please drop
>> > them.
>> I think you don't appreciate the role of assertions in making code
>> ea
Pekka Enberg wrote:
>Hi Hans,
>
>On 6/22/05, Hans Reiser <[EMAIL PROTECTED]> wrote:
>
>
>>I would in particular love to have you Andi Kleen do a full review of V4
>>if you could be that generous with your time, as I liked much of the
>>advice you gave us
Thanks fs, Edward, can you or vs look at this?
Hans
fs wrote:
>Seems my domain is filtered , so I resend the modified version.
>
>Related FS:
>ReiserFS
>
>Related Files:
>fs/reiserfs/inode.c
>
>Bug description:
>Make a ReiserFS partition in USB storage HDD, create a test file
>with
>
Jeff Garzik wrote:
> We have to maintain said ugly code for decades.
No you don't, I do.
>> filesystem, but if so, it will have to do it much more slowly. Take the
>> good ideas -- things like plugins -- and make them at least look like
>> incremental updates to the current VFS, and make them a
Christoph Hellwig wrote:
>
>
>
>
>>What is wrong with having one file in the FS use a write only plugin, in
>>which the encrypion key is changed with every append in a forward but
>>not backward computable manner, and in order to read a file you must
>>either have a key that is stored on another
Correct me if I am wrong:
What exists currently in VFS are vector instances, not classes. Plugins,
selected by pluginids, are vector classes, with each pluginid selecting
a vector class. You propose to have the vector class layer (aka plugin
layer) in reiser4 export the vector instance to VFS for
Jeff Garzik wrote:
>> after it has undergone massive surgery, and Namesys is bankrupt, and
>> users have given up and moved on to XFS. But the massive surgery should
>> happen eventually, partly to make all filesystems better (see below),
>> and partly to make the transition easier and more palat
Jeff Garzik wrote:
>
>
> "Hans' team says its good stuff" is not a criteria for merging.
>
>
Try benchmarking it. Maybe benchmarks mean more than our
chattering. at least to the users.
Andi Kleen wrote:
>
> Just there are doubts that your
>code follows the Linux coding standards enough to not be a undue
>mainteance burden in mainline.
>
We get only a few bugfixes from outsiders, and the rest are done by us.
The customers who buy licenses in addition to the GPL from us for
hund
Andi Kleen wrote:
> Christoph does a lot of reviewing
>
and he is notorious for making needed linux contributors go away and not
come back, and I won't say which famous person on this mailing list told
me that
>and your child definitely
>is in serious need of that to be mergeable. I'm sure C
Andi Kleen wrote:
>On Tue, Jun 21, 2005 at 11:44:55AM -0700, Hans Reiser wrote:
>
>
>>vs and zam, please comment on what we get from our profiler and spinlock
>>debugger that the standard tools don't supply. I am sure you have a
>>reason, but now is the time
Christoph,
Reiser4 users love the plugin concept, and all audiences which have
listened to a presentation on plugins have been quite positive about
it. Many users think it is the best thing about reiser4. Can you
articulate why you are opposed to plugins in more detail? Perhaps you
are simply n
[EMAIL PROTECTED] wrote:
>ReiserFS/Reiser4 is supposed to be something like an efficient storage DB
>for lots of small files. Problem: perusing the files' metadata information
>(last modified time, file size etc.) takes much too much time -- most
>probably because that data is scattered all over t
E.Gryaznova wrote:
> Hello.
>
> Thank you for the report.
>
> VMWare/reiser4 is known problem, we can reproduce it. But
> unfortunately I can't estimate when this will be fixed.
> Reiser4 format was changed in reiser4-5 patch for 2.6.11, reiser4progs
> for this format are not ready yet.
>
> Than
thanks fs
Vitaly Fertman wrote:
>On Sunday 12 June 2005 02:42, Paul Gear wrote:
>
>
>>Hi folks,
>>
>>After filling my reiserfs with backups, i ended up with a corrupt
>>filesystem. I'm running Debian 3.1 (sarge), kernel 2.6.8-2-k7, and
>>reiserfsprogs 3.6.19-1.
>>
>>I don't care about this filesystem and
Nikita Danilov wrote:
>Hans Reiser writes:
> > Nikita Danilov wrote:
> >
> > >
> > >But cycles are "solvable" in current file systems too: they simply do
> > >not exist there.
> > >
> > >
> > Yes, but Nikita, cycl
Nikita Danilov wrote:
>
>But cycles are "solvable" in current file systems too: they simply do
>not exist there.
>
>
Yes, but Nikita, cycles represent semantic functionality that has value
because being able to embody more expressions means more power of
expression. If some way can be found to
Alexander G. M. Smith wrote:
>Hans Reiser wrote on Tue, 31 May 2005 11:32:04 -0700:
>
>
>>What about if we have it that only the first name a directory is created
>>with counts towards its reference count, and that if the directory is
>>moved if it is moved from i
Nikita Danilov wrote:
>Jonathan Briggs writes:
> > On Tue, 2005-05-31 at 12:30 -0400, [EMAIL PROTECTED] wrote:
> > > On Tue, 31 May 2005 08:04:42 PDT, Hans Reiser said:
> > >
> > > > >Cycle may consists of more graph nodes than fits into memory.
&
sonally, I would allow deleting the OID. It would be a convenient
>way to be sure every instance of a file was deleted.
>
>On Tue, 2005-05-31 at 09:59 -0700, Hans Reiser wrote:
>
>
>>What happens when you unlink the True Name?
>>
>>Hans
>>
>>Jonathan
Jonathan Briggs wrote:
>
>Why innovate in the filesystem though, when it would work just as well
>or better in the VFS layer?
>
Why don't we just have one filesystem, think of the advantages.
;-)
I don't try to get other people to follow my lead anymore, I just ship
code that works. Putting
What happens when you unlink the True Name?
Hans
Jonathan Briggs wrote:
>
>You can avoid cycles by redefining the problem.
>
>Every file or "data object" has one single True Name which is their
>inode or OID. Each data object then has one or more "names" as
>properties. Names are either single
Nikita Danilov wrote:
>Alexander G. M. Smith writes:
> > Nikita Danilov wrote on Mon, 30 May 2005 15:00:52 +0400:
> > > Nothing in VFS prevents files from supporting both read(2) and
> > > readdir(3). The problem is with link(2): VFS assumes that directories
> > > form _tree_, that is, every direc
I think what Alex is suggesting below is reasonable and something
resembling it should be done, though I will not go into details on it
until we have some working code
Hans
Alexander G. M. Smith wrote:
>[EMAIL PROTECTED] wrote on Sat, 28 May 2005 15:42:35 -0400:
>
>
>>I'm not Hans, but I *
[EMAIL PROTECTED] wrote:
>On Fri, 27 May 2005 23:56:35 CDT, David Masover said:
>
>
>
>>Hans, comment please? Is this approaching v5 / v6 / Future Vision? It
>>does seem more than a little "clunky" when applied to v4...
>>
>>
Well, if you read our whitepaper, we consider relational algebra
Artem B. Bityuckiy wrote:
> Hello,
>
> I'm designing new flash file system. And I'm thinking about the
> possibility to write plugins for ReiserFS to implement it (I know, it
> sounds crazy). I didn't thoroughly explore is it possible or not yet.
>
> I'm almost certain that it is impossible to do
[EMAIL PROTECTED] wrote:
>On Mon, 23 May 2005 12:52:12 +0300, Markus =?UNKNOWN?Q?T=F6rnqvist?= said:
>
>
>>On Sun, May 22, 2005 at 07:22:51PM -0500, David Masover wrote:
>>
>>
>>>Of course, I've worked on sufficiently few big projects that I'm still
>>>naive enough to believe that unit tests
Markus Törnqvist wrote:
>On Sun, May 22, 2005 at 12:43:52AM -0700, Hans Reiser wrote:
>
>
>>What Vladimir failed to say was that it is our recent changes to
>>accomodate the kernel maintainers that are unstable, we had previously
>>reached the point where none of ou
What Vladimir failed to say was that it is our recent changes to
accomodate the kernel maintainers that are unstable, we had previously
reached the point where none of our internal tests could make it crash.
I hope that he did not put these unstable changes on our website for
users to see them wit
David Masover wrote:
> Hans Reiser wrote:
>
> >Mark Piper wrote:
>
>
> >>This summer, I will be starting a 3.5-month project to create an
> >>Installable File System Driver (IFSD) to read ReiserFS under Microsoft
> >>Windows, similar to ext2fsd. (
Mark Piper wrote:
> This summer, I will be starting a 3.5-month project to create an
> Installable File System Driver (IFSD) to read ReiserFS under Microsoft
> Windows, similar to ext2fsd. (The project is a practicum to complete
> my degree in software engineering from Carnegie Mellon.)
I woul
Sean McGrath wrote:
>
What is an opaque name?
>>>
>>> By "opaque name" I mean a name that is purely a label. A name that
>>> cannot be interpreted as a query expression.
>>>
>>
>>
>> Isn't query just another name for name?
>>
>>
>>
> That is a major philosop
Sean McGrath wrote:
> Hans Reiser wrote:
>
>> Sean McGrath wrote:
>>
>>
>>
>>> The thing that interests me most is the difference (if any) between
>>> giving a stream of bytes an opaque name e.g. "Chapter 1 of my
>>> book.sxw" v
Sean McGrath wrote:
> The thing that interests me most is the difference (if any) between
> giving a stream of bytes an opaque name e.g. "Chapter 1 of my
> book.sxw" versus giving a stream of bytes a query expression that can
> also be considered an opaque name e.g.
> "/book/chapter[1] "
>
What is
Peter Foldiak wrote:
>On Tue, 2005-05-10 at 16:14, [EMAIL PROTECTED] wrote:
>
>
>>On Tue, 10 May 2005 10:39:23 BST, Peter Foldiak said:
>>
>>
>>>Back in November 2004, I suggested on the linux-kernel and reiserfs
>>>lists that the Reiser4 architecture could allow us to abolish the
>>>unnatur
I agree with the below in that sometimes you want to see a collection of
stuff as one file, and sometimes you want to see it as a tree, and that
file format browsers can be integrated into file system browsers to look
seamless to users.
A quibble: A name is just a means to select a file; he is com
Dr. Giovanni A. Orlando wrote:
> Hans Reiser wrote:
>
>> I think someone is going to pay us to write the online repacker in the
>> very near future, though I can't say their name.
>>
>> Giovanni, if by parted support you mean that you are going to write a
>&
I think someone is going to pay us to write the online repacker in the
very near future, though I can't say their name.
Giovanni, if by parted support you mean that you are going to write a
resizer (and now that I take a moment to remember what parted does it
seems certain you do mean that), I wis
Dr. Giovanni A. Orlando wrote:
> Hi Everyone,
>
>I am looking to know if someone have time to share with me to add
> the necessary code
>inside 'parted' to support Reiser4.
>
>May be 1 or 2 hours per day.
>
>The reference page is:
> http://www.gnu.org/software/parted/#maillis
Adrian Ulrich wrote:
Hi,
IIRC a fund drive was talked about earlier and for some reason
discarded. Can't even remember who the guy behind it was, I'm afraid.
It was me..
And i'd still buy them a Mac.. No problem..
-- Adrian
We won't turn down hardware, but it might be a few months befor
Sander Sweers wrote:
On 02/05/05, Hans Reiser <[EMAIL PROTECTED]> wrote:
Vitaly, if he is doing something with apt, that means he is probably
using debian, which means they may have broken things, which means you
need to look into it and fix things and report to me on it.
AFAIK gru
Vitaly, if he is doing something with apt, that means he is probably
using debian, which means they may have broken things, which means you
need to look into it and fix things and report to me on it.
Nicolas Smallwood wrote:
Hello,
My question concerns searching through a group of files on reiser4.
Assume that we are dealing with a directory full of files (say a few
million or so).
If I am currently viewing a given file, and wish to iterate to the
next file in the directory,
is there a metho
I propose that if a mask contains a symlink, that it be a fallthru to
where the link points to, and that it transform the name being looked up
in the manner usual for symlinks that are followed.
I believe the result will be a small amount of code, and it will
effectively implement views. Am I
Vladimir Saveliev wrote:
Hello
On Fri, 2005-04-15 at 16:37, Szabolcs Illes wrote:
Hi,
I have found these entries in my system log: (maybe it's a reiserfs4 bug)
Mar 14 20:06:15 sunset reiser4[umount(8489)]: reiser4_handle_error (fs/reiser4/vfs_ops.c:1432)[foobar-42]:
Mar 14 20:06:15 sunset reiser
The current repacker code uses the allocate on flush code and the
transaction code, and walks through the tree sorting it, walking in both
directions.
Hans
David Masover wrote:
> Hans Reiser wrote:
>
> >David Masover wrote:
>
>
> >>I realize that this may not be qu
David Masover wrote:
>
>
> I realize that this may not be quite the industrial-strength repacker
> that you wanted, but it should be immediately useful, which is a lot
> better than "We might do it if you pay us."
Just wait a little, and shortly after we go into the kernel we will work
on the rep
Alex Zarochentsev wrote:
>On Mon, Apr 11, 2005 at 04:30:53PM +0200, Stefan Andersson wrote:
>
>
>>Hi,
>>
>>I have a disk array wich I used reiserfs(v3) on, and got 932G.
>>Now I started to test reiser4 on it and get less space, 886G.
>>
>>Is it suppose to be like this or is there something wrong
Nate, give them the code, and use the latest text we wrote for the
moderation policy guidelines.
Jagannadha Bhattu wrote:
>Which is the best way to start learing reiserfs internals, so that I
>can contribute to it. If there are any suggestions on good books to
>read, please let me know.
>
>Thanks
>Jagannadha.
>
>
>
>
website and then source code are the way. Source code is well commented.
David Masover wrote:
> reiser4-for-2.6 stops at 2.6.10, and after that, all I can find are
> patches to mm. Reiser4 seems stable for me, mm does not. Are there
> still patches somewhere?
There was a 2.6.11 patch on our website last week, but I did hear that
vs had found a bug, so maybe he pulle
Christian Mayrhuber wrote:
>
>
> I guess dbench-3.x stress testing is missing from your grand archive ;-)
>
Yes, actually, I suspect it is. Elena, please comment.
Suggestion: If you want casual people to actually read code, you need to
send it as uncompressed patches. Vitaly, please look at this.
I think we would only want to use the algorithm you describe below after
extensively warning the user that they should instead first copy it to a
working hard dri
Pallavi Dalya wrote:
> hello,
> By doing debugfs on reiser4 and studying it I understand that the
> disk block address of the root node of on-disk tree as well as the
> complete on-disk tree gets changed due to the creation of extent pointer.
> For example:: suppose the root node is initally cr
E.Gryaznova wrote:
> Hello.
>
> Szabolcs Illes wrote:
>
>> Hi,
>>
>> When I tried to umount my reiserfs4 partition I got this error
>> message in the kernel log:
>>
> [skip]
>
>>
>> [EMAIL PROTECTED]:~#
>>
>> I am using the latest kernel 2.6.11 with the patch available from
>> ftp://ftp.namesys.co
Dr. Giovanni A. Orlando wrote:
> Hi,
>
>Some days ago I hear aboout the Reser 4.1.
>
>Is this true?
>
>Have Reiser4 moved to a new release?
Not yet. 4.1 is entering alpha test. Some details are at
www.namesys.com/blackbox_security.html
>
> Thanks,
> Giovanni.
>
Gorazd Golob wrote:
> Hi!
>
>>>
>> Probably you just have a lot of dirty buffers in RAM and they need to
>> flush to disk?
>>
> Hmm.. I'll try explain .. Before I did sync or unmount, application,
> that previosly wrote to reiser4 partition was closed. In moment of
> running sync or umount OS had
Gorazd Golob wrote:
> hi!
>
> I have strangely long delay (still waiting at the time) when
> unmounting or syncing partition with reiser4. At the same time writes
> are occuring to disk subsystem - when checking vmstat and of course
> checking disk activity light ;).
>
> Why does it take so long a
Chris/Jeff, can you modify your code to whenever it sees an I/O error,
to say "I/O errors usually indicate bad hardware not bad software,
probably you need to get a new disk and use dd_rescue to copy everything
to it."?
Thanks,
Hans
Linas Vepstas wrote:
>Hi,
>
>I've been experimenting with auto
501 - 600 of 1230 matches
Mail list logo
