my dream come true
Do not ignore me please, I found your email somewhere and now decided to write you. I am coming to your place in few weeks and thought we can meet each other. Let me know if you do not mind. I am a nice pretty girl. Don't reply to this email. Email me direclty at [EMAIL PROTECTED]
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
Peter van Hardenberg wrote: >On Tuesday 28 February 2006 12:04, Hans Reiser wrote: > > >>Maybe we can put a button on our webpage labeled reiser4 wiki maintained >>by pvh. There is no chat equivalent of mailto: is there? Maybe we >>should also have a button labeled chatrooms which contains a page >>describing where to find our chatrooms, etc. >> >> > >An excellent idea. I know there is already a Reiser IRC channel on OFTC. The >URL irc://irc.oftc.net/reiser4 is understood by some programs. I have added >the link to my wiki front page. > > Ok, that works for me, flx, please add it to our web page. >If involvement grows, I will probably improve the Reiser4 wiki's hosting >situation, at which point I will redirect the URL automatically and post the >new URL here. > >Tell me, do you have an public access SVN or CVS repository I could link the >wiki to for source references? > > we use git these days, sigh. >-pvh > > >
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
On Tuesday 28 February 2006 16:03, you wrote: > On Tuesday 28 February 2006 17:24, you wrote: > > No i don't have SVN or CVS. Also i think it will be a nice feature of the > wiki if it explains how to setup a development enviroment. It does, thanks to Ryan Nordman's efforts. (Further additions, corrections, and alternate configurations are welcome.) -p -- Peter van Hardenberg ([EMAIL PROTECTED]) Victoria, BC, Canada pgpjXW7wI1U9o.pgp Description: PGP signature
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
On Tuesday 28 February 2006 12:04, Hans Reiser wrote: > Maybe we can put a button on our webpage labeled reiser4 wiki maintained > by pvh. There is no chat equivalent of mailto: is there? Maybe we > should also have a button labeled chatrooms which contains a page > describing where to find our chatrooms, etc. An excellent idea. I know there is already a Reiser IRC channel on OFTC. The URL irc://irc.oftc.net/reiser4 is understood by some programs. I have added the link to my wiki front page. If involvement grows, I will probably improve the Reiser4 wiki's hosting situation, at which point I will redirect the URL automatically and post the new URL here. Tell me, do you have an public access SVN or CVS repository I could link the wiki to for source references? -pvh -- Peter van Hardenberg ([EMAIL PROTECTED]) Victoria, BC, Canada pgpvjj1EeFuYe.pgp Description: PGP signature
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
Yoanis Gil Delgado wrote: >On Tuesday 28 February 2006 16:53, Marcus Furlong wrote: > > >>>On Tuesday 28 February 2006 12:07, Yoanis Gil Delgado wrote: >>> >>> On Tuesday 28 February 2006 01:24, Peter van Hardenberg wrote: We most take the advance.I suggest to all people interested in this to spent a full weekend creating such a plugin. There is a possibility of failure but. we will gather enough question for the people at namesys and they can share some ligth. Then we spent another weekend and so on... >>>Yoanis, this is a great idea! We can collaborate via IRC and the wiki and >>>share our discoveries. I will join this project. Who else will? >>> >>> >>Count me in too. I think it's a great idea. Any chance of having someone >>from namesys on hand to participate as well in case we hit any brick walls? >> >> >Yes that would be excellent. But we must think in the worst scenerio. We must >start walking so when we hit the wall people at namesys said: > "This kids really need help" > >P.D: Reiser please don't let us hit the wall :) > > > > We won't. But we will be asleep at frequent intervals. ;-)
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
On Tuesday 28 February 2006 16:53, Marcus Furlong wrote: > > On Tuesday 28 February 2006 12:07, Yoanis Gil Delgado wrote: > >> On Tuesday 28 February 2006 01:24, Peter van Hardenberg wrote: > >> We most take the advance.I suggest to all people interested in this to > >> spent a full weekend creating such a plugin. There is a possibility of > >> failure but. we will gather enough question for the people at > >> namesys and they can share some ligth. Then we spent another weekend and > >> so on... > > > > Yoanis, this is a great idea! We can collaborate via IRC and the wiki and > > share our discoveries. I will join this project. Who else will? > > Count me in too. I think it's a great idea. Any chance of having someone > from namesys on hand to participate as well in case we hit any brick walls? Yes that would be excellent. But we must think in the worst scenerio. We must start walking so when we hit the wall people at namesys said: "This kids really need help" P.D: Reiser please don't let us hit the wall :)
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
Marcus Furlong wrote: >>On Tuesday 28 February 2006 12:07, Yoanis Gil Delgado wrote: >> >> >>>On Tuesday 28 February 2006 01:24, Peter van Hardenberg wrote: >>>We most take the advance.I suggest to all people interested in this to >>>spent a full weekend creating such a plugin. There is a possibility of >>>failure but. we will gather enough question for the people at namesys >>>and they can share some ligth. Then we spent another weekend and so on... >>> >>> >>Yoanis, this is a great idea! We can collaborate via IRC and the wiki and >>share our discoveries. I will join this project. Who else will? >> >> > >Count me in too. I think it's a great idea. Any chance of having someone >from namesys on hand to participate as well in case we hit any brick walls? > > > > > That kind of depends on the timezone you do it in.;-) Go ahead and get started, and we will participate in an ad-hoc way. Tell us where you are doing your talks, and when you have questions send emails or otherwise ping us. Nobody on our team in Russia will be awake for at least 8 hours. Hans
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
> On Tuesday 28 February 2006 12:07, Yoanis Gil Delgado wrote: >> On Tuesday 28 February 2006 01:24, Peter van Hardenberg wrote: >> We most take the advance.I suggest to all people interested in this to >> spent a full weekend creating such a plugin. There is a possibility of >> failure but. we will gather enough question for the people at namesys >> and they can share some ligth. Then we spent another weekend and so on... > > Yoanis, this is a great idea! We can collaborate via IRC and the wiki and > share our discoveries. I will join this project. Who else will? Count me in too. I think it's a great idea. Any chance of having someone from namesys on hand to participate as well in case we hit any brick walls?
Re: Reiser4 unlink performance
On Tuesday 28 February 2006 23:42, Hans Reiser wrote: > Alexander Zarochentsev wrote: > >On Tuesday 28 February 2006 22:56, Hans Reiser wrote: > >>Alexander Zarochentsev wrote: > >>>On Tuesday 28 February 2006 22:11, Hans Reiser wrote: > Alec H. Peterson wrote: > >Hi Alexander, > > > >On Feb 26, 2006, at 13:42, Alexander Zarochentsev wrote: > >>Which kernel version and reiser4 patches were used? > > > >2.6.15.4r4 kernel, > >reiser4-for-2.6.15-1.patch > > > >>Is the system SMP? > > > >Yes. > > > >>No, "Flushing like mad" usually indicates a bug. > > Please describe it in more detail. > >>> > >>>The flush algorithm designed to make progress in any iteration. > >>>"flushing like mad" messages usually indicates that the flush > >>> can't make progress. > >> > >>Yet more detail please. > > > >the algorithm does not work as designed, it is a design bug or an > >implementation bug ;) > > I seem to remember vs saying this message could be ignored safely at > times in the past, which is why I am asking you for more details. We have improved handling of truncate/flush races, especially if formatted nodes are deleted. Now I think that any truncate/flush race can be resolved w/o having those too many useless iterations of jnode_flush. > Hans -- Alex.
Re: Reiser4 unlink performance
Alexander Zarochentsev wrote: >On Tuesday 28 February 2006 22:56, Hans Reiser wrote: > > >>Alexander Zarochentsev wrote: >> >> >>>On Tuesday 28 February 2006 22:11, Hans Reiser wrote: >>> >>> Alec H. Peterson wrote: >Hi Alexander, > >On Feb 26, 2006, at 13:42, Alexander Zarochentsev wrote: > > >>Which kernel version and reiser4 patches were used? >> >> >2.6.15.4r4 kernel, >reiser4-for-2.6.15-1.patch > > > >>Is the system SMP? >> >> >Yes. > > > >>No, "Flushing like mad" usually indicates a bug. >> >> Please describe it in more detail. >>>The flush algorithm designed to make progress in any iteration. >>>"flushing like mad" messages usually indicates that the flush can't >>>make progress. >>> >>> >>Yet more detail please. >> >> > >the algorithm does not work as designed, it is a design bug or an >implementation bug ;) > > > I seem to remember vs saying this message could be ignored safely at times in the past, which is why I am asking you for more details. Hans
Re: Reiser4 unlink performance
On Tuesday 28 February 2006 22:56, Hans Reiser wrote: > Alexander Zarochentsev wrote: > >On Tuesday 28 February 2006 22:11, Hans Reiser wrote: > >>Alec H. Peterson wrote: > >>>Hi Alexander, > >>> > >>>On Feb 26, 2006, at 13:42, Alexander Zarochentsev wrote: > Which kernel version and reiser4 patches were used? > >>> > >>>2.6.15.4r4 kernel, > >>>reiser4-for-2.6.15-1.patch > >>> > Is the system SMP? > >>> > >>>Yes. > >>> > No, "Flushing like mad" usually indicates a bug. > >> > >>Please describe it in more detail. > > > >The flush algorithm designed to make progress in any iteration. > >"flushing like mad" messages usually indicates that the flush can't > >make progress. > Yet more detail please. the algorithm does not work as designed, it is a design bug or an implementation bug ;) > >>>Good to know. > >>> > >>>Thanks! > >>> > >>>Alec -- Alex.
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
Maybe we can put a button on our webpage labeled reiser4 wiki maintained by pvh. There is no chat equivalent of mailto: is there? Maybe we should also have a button labeled chatrooms which contains a page describing where to find our chatrooms, etc.
Re: Reiser4 unlink performance
Alexander Zarochentsev wrote: >On Tuesday 28 February 2006 22:11, Hans Reiser wrote: > > >>Alec H. Peterson wrote: >> >> >>>Hi Alexander, >>> >>>On Feb 26, 2006, at 13:42, Alexander Zarochentsev wrote: >>> >>> Which kernel version and reiser4 patches were used? >>>2.6.15.4r4 kernel, >>>reiser4-for-2.6.15-1.patch >>> >>> >>> Is the system SMP? >>>Yes. >>> >>> >>> No, "Flushing like mad" usually indicates a bug. >>Please describe it in more detail. >> >> >> > >The flush algorithm designed to make progress in any iteration. >"flushing like mad" messages usually indicates that the flush can't >make progress. > > Yet more detail please. > > >>>Good to know. >>> >>>Thanks! >>> >>>Alec >>> >>> >>!DSPAM:4404a06b108681480917376! >> >> > > >
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
Yoanis and Peter, you are very generous with your time. Thank you. Hans Yoanis Gil Delgado wrote: >On Tuesday 28 February 2006 01:24, Peter van Hardenberg wrote: > > >>Hans, >> >>you've said that these kinds of plugins should be something a weekend >>warrior could tackle. Our group had a real stab and dumped hundreds of man >>hours into the project with little effect. Admittedly, we were not >>experienced kernel hackers, but we were all comfortable in low-level C and >>quite happy to read source. >> >>I request that a simple plugin be maintained as a standalone patch to >>Reiser4 >> >>Ideally, there would be a small set of these plugins demonstrating how to >>create a new plugin which operates within the existing disk structure, and >>one that extends the on-disk format in a safe way. >> >>This would allow interested parties to see in isolation what a Reiser4 >>plugin looks like and would further provide a conceptual grappling point >>for the development of a new plugin. >> >>I have been getting requests for just such a plugin to be added to my >>reiser4 developer's wiki (http://pvh.ca/trac/wiki/reiser4) at a rate of >>about one every two months. A few successful third-party plugins would >>hopefully increase interest in this. >> >>I realise you and your team are up to your necks in serious work on >>hardcore lowlevel material, but I believe a brief diversion of some of your >>resources would provide a significant reward. >> >>Right now, the cost-of-entry appears to be set too high for developers >>outside your team to approach the project. >> >>If this information is already out there somewhere, great. I will integrate >>it in the R4DevWiki and answer questions as best I can. If anyone out there >>disagrees with me about the current difficulty of producing even a simple >>plugin, let them prove me wrong with a patch. >> >>-pvh >> >> > >We most take the advance.I suggest to all people interested in this to spent a >full weekend creating such a plugin. There is a possibility of failure >but. we will gather enough question for the people at namesys and they >can share some ligth. Then we spent another weekend and so on... > > > > > > >
Re: Reiser4 unlink performance
On Tuesday 28 February 2006 22:11, Hans Reiser wrote: > Alec H. Peterson wrote: > > Hi Alexander, > > > > On Feb 26, 2006, at 13:42, Alexander Zarochentsev wrote: > >> Which kernel version and reiser4 patches were used? > > > > 2.6.15.4r4 kernel, > > reiser4-for-2.6.15-1.patch > > > >> Is the system SMP? > > > > Yes. > > > >> No, "Flushing like mad" usually indicates a bug. > > Please describe it in more detail. > The flush algorithm designed to make progress in any iteration. "flushing like mad" messages usually indicates that the flush can't make progress. > > Good to know. > > > > Thanks! > > > > Alec > > !DSPAM:4404a06b108681480917376! -- Alex.
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
On Tuesday 28 February 2006 14:41, Peter van Hardenberg wrote: > On Tuesday 28 February 2006 12:07, Yoanis Gil Delgado wrote: > > On Tuesday 28 February 2006 01:24, Peter van Hardenberg wrote: > > We most take the advance.I suggest to all people interested in this to > > spent a full weekend creating such a plugin. There is a possibility of > > failure but. we will gather enough question for the people at namesys > > and they can share some ligth. Then we spent another weekend and so on... > > Yoanis, this is a great idea! We can collaborate via IRC and the wiki and > share our discoveries. I will join this project. Who else will? Yes IRC is a good way of communication this will bring to life reiser4 IRC channel :). Hope we can get enough hackers. As soon as we have then we must start to organize the "party".
Re: Reiser4 unlink performance
I meant for Zam to describe it in more detail, sorry about that. :-/
Hans
Alec H. Peterson wrote:
> Hi Hans,
>
> On Feb 28, 2006, at 12:11, Hans Reiser wrote:
>
>> Please describe it in more detail.
>
>
> Well, the error I'm getting is this:
>
> Feb 21 13:10:22 ecbuild-10 kernel: WARNING: Flushing like mad: 16384
>
> The C program I'm running to do the test is this:
>
> main(int argc, char **argv)
> {
> char buf[1024];
> char dir[1024];
> int i,j,k;
> int ret;
> int fd;
> int *sequence;
> struct timeval start, unlinktime, end;
>
> if(argc != 2)
> {
> fprintf(stderr, "Usage: %s \n", argv[0]);
> exit(1);
> }
>
> strncpy(dir, argv[1], 1024);
>
> if(chdir(dir))
> {
> perror("chdir");
> exit(1);
> }
>
> for(i = 0; i < 256; i++)
> {
> snprintf(buf, 1024, "%d", i);
> ret = mkdir(buf, S_IRWXU);
> if(ret && (errno != EEXIST))
> {
> perror("mkdir");
> exit(1);
> }
> }
>
>
> {
> sequence = sequence2;
> gettimeofday(&start, NULL);
> fprintf(stderr, "Starting %d run %d.%d.\n",
> 256 * 2, start.tv_sec, start.tv_usec);
>
> for(i = 0; i < 256; i++)
> {
> for(j = 0; j < 2; j++)
> {
> snprintf(buf, 1024, "%d/%d", i, j);
> fd = open(buf, O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
> if(fd == -1)
> {
> perror("open");
> exit(1);
> }
> close(fd);
> }
> fprintf(stderr, "Done %d\n", i);
> }
>
> gettimeofday(&unlinktime, NULL);
> fprintf(stderr, "Starting %d unlink %d.%d, elapsed time was %d.\n",
> 256 * 2, unlinktime.tv_sec, unlinktime.tv_usec,
> unlinktime.tv_sec - start.tv_sec);
>
> for(i = 0; i < 2; i++)
> {
> for(j = 0; j < 256; j++)
> {
> snprintf(buf, 1024, "%d/%d", j, sequence[i]);
> unlink(buf);
> if(fd == -1)
> {
> perror("unlink");
> exit(1);
> }
> }
> fprintf(stderr, "Done %d\n", i);
> }
>
> gettimeofday(&end, NULL);
> fprintf(stderr, "Done with %d unlink %d.%d, elapsed time was %d. \n",
> 2 * 256, end.tv_sec, end.tv_usec,
> end.tv_sec - unlinktime.tv_sec);
> }
>
> exit(0);
> }
>
> sequence2 is an array which contains a sequence from 1 to 2
> randomly ordered.
>
> Alec
>
>
>
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
On Tuesday 28 February 2006 12:07, Yoanis Gil Delgado wrote: > On Tuesday 28 February 2006 01:24, Peter van Hardenberg wrote: > We most take the advance.I suggest to all people interested in this to > spent a full weekend creating such a plugin. There is a possibility of > failure but. we will gather enough question for the people at namesys > and they can share some ligth. Then we spent another weekend and so on... Yoanis, this is a great idea! We can collaborate via IRC and the wiki and share our discoveries. I will join this project. Who else will? -- Peter van Hardenberg ([EMAIL PROTECTED]) Victoria, BC, Canada pgpFToE68EfrS.pgp Description: PGP signature
Re: Reiser4 unlink performance
Hi Hans,
On Feb 28, 2006, at 12:11, Hans Reiser wrote:
Please describe it in more detail.
Well, the error I'm getting is this:
Feb 21 13:10:22 ecbuild-10 kernel: WARNING: Flushing like mad: 16384
The C program I'm running to do the test is this:
main(int argc, char **argv)
{
char buf[1024];
char dir[1024];
int i,j,k;
int ret;
int fd;
int *sequence;
struct timeval start, unlinktime, end;
if(argc != 2)
{
fprintf(stderr, "Usage: %s \n", argv[0]);
exit(1);
}
strncpy(dir, argv[1], 1024);
if(chdir(dir))
{
perror("chdir");
exit(1);
}
for(i = 0; i < 256; i++)
{
snprintf(buf, 1024, "%d", i);
ret = mkdir(buf, S_IRWXU);
if(ret && (errno != EEXIST))
{
perror("mkdir");
exit(1);
}
}
{
sequence = sequence2;
gettimeofday(&start, NULL);
fprintf(stderr, "Starting %d run %d.%d.\n",
256 * 2, start.tv_sec, start.tv_usec);
for(i = 0; i < 256; i++)
{
for(j = 0; j < 2; j++)
{
snprintf(buf, 1024, "%d/%d", i, j);
fd = open(buf, O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
if(fd == -1)
{
perror("open");
exit(1);
}
close(fd);
}
fprintf(stderr, "Done %d\n", i);
}
gettimeofday(&unlinktime, NULL);
fprintf(stderr, "Starting %d unlink %d.%d, elapsed time was %d.\n",
256 * 2, unlinktime.tv_sec, unlinktime.tv_usec,
unlinktime.tv_sec - start.tv_sec);
for(i = 0; i < 2; i++)
{
for(j = 0; j < 256; j++)
{
snprintf(buf, 1024, "%d/%d", j, sequence[i]);
unlink(buf);
if(fd == -1)
{
perror("unlink");
exit(1);
}
}
fprintf(stderr, "Done %d\n", i);
}
gettimeofday(&end, NULL);
fprintf(stderr, "Done with %d unlink %d.%d, elapsed time was %d.
\n",
2 * 256, end.tv_sec, end.tv_usec,
end.tv_sec - unlinktime.tv_sec);
}
exit(0);
}
sequence2 is an array which contains a sequence from 1 to 2
randomly ordered.
Alec
Re: Reiser4 unlink performance
Alec H. Peterson wrote: > Hi Alexander, > > On Feb 26, 2006, at 13:42, Alexander Zarochentsev wrote: > >> >> Which kernel version and reiser4 patches were used? > > > 2.6.15.4r4 kernel, > reiser4-for-2.6.15-1.patch > >> Is the system SMP? > > > Yes. > >> >> No, "Flushing like mad" usually indicates a bug. > > Please describe it in more detail. > Good to know. > > Thanks! > > Alec > > > >
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
On Tuesday 28 February 2006 01:24, Peter van Hardenberg wrote: > Hans, > > you've said that these kinds of plugins should be something a weekend > warrior could tackle. Our group had a real stab and dumped hundreds of man > hours into the project with little effect. Admittedly, we were not > experienced kernel hackers, but we were all comfortable in low-level C and > quite happy to read source. > > I request that a simple plugin be maintained as a standalone patch to > Reiser4 > > Ideally, there would be a small set of these plugins demonstrating how to > create a new plugin which operates within the existing disk structure, and > one that extends the on-disk format in a safe way. > > This would allow interested parties to see in isolation what a Reiser4 > plugin looks like and would further provide a conceptual grappling point > for the development of a new plugin. > > I have been getting requests for just such a plugin to be added to my > reiser4 developer's wiki (http://pvh.ca/trac/wiki/reiser4) at a rate of > about one every two months. A few successful third-party plugins would > hopefully increase interest in this. > > I realise you and your team are up to your necks in serious work on > hardcore lowlevel material, but I believe a brief diversion of some of your > resources would provide a significant reward. > > Right now, the cost-of-entry appears to be set too high for developers > outside your team to approach the project. > > If this information is already out there somewhere, great. I will integrate > it in the R4DevWiki and answer questions as best I can. If anyone out there > disagrees with me about the current difficulty of producing even a simple > plugin, let them prove me wrong with a patch. > > -pvh We most take the advance.I suggest to all people interested in this to spent a full weekend creating such a plugin. There is a possibility of failure but. we will gather enough question for the people at namesys and they can share some ligth. Then we spent another weekend and so on...
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
XFS is larger than Reiser4... Peter van Hardenberg wrote: >Hans, > >you've said that these kinds of plugins should be something a weekend warrior >could tackle. Our group had a real stab and dumped hundreds of man hours into >the project with little effect. Admittedly, we were not experienced kernel >hackers, but we were all comfortable in low-level C and quite happy to read >source. > >I request that a simple plugin be maintained as a standalone patch to Reiser4. > I will accept a patch doing that. Unfortunately, my guys really need to focus on getting done the stuff needed for us to get into the kernel first before we could tackle that. > > >Ideally, there would be a small set of these plugins demonstrating how to >create a new plugin which operates within the existing disk structure, and >one that extends the on-disk format in a safe way. > >This would allow interested parties to see in isolation what a Reiser4 plugin >looks like and would further provide a conceptual grappling point for the >development of a new plugin. > >I have been getting requests for just such a plugin to be added to my reiser4 >developer's wiki (http://pvh.ca/trac/wiki/reiser4) at a rate of about one >every two months. A few successful third-party plugins would hopefully >increase interest in this. > >I realise you and your team are up to your necks in serious work on hardcore >lowlevel material, but I believe a brief diversion of some of your resources >would provide a significant reward. > >Right now, the cost-of-entry appears to be set too high for developers outside >your team to approach the project. > > I share your concerns on this. >If this information is already out there somewhere, great. I will integrate it >in the R4DevWiki and answer questions as best I can. If anyone out there >disagrees with me about the current difficulty of producing even a simple >plugin, let them prove me wrong with a patch. > >-pvh > > >
Re: Plugin Patch (was Re: creating live virtual files by concatenation)
Peter van Hardenberg wrote: > you've said that these kinds of plugins should be something a weekend > warrior could tackle. Our group had a real stab and dumped hundreds of man > hours into the project with little effect. Admittedly, we were not > experienced kernel hackers, but we were all comfortable in low-level C and > quite happy to read source. > > I request that a simple plugin be maintained as a standalone patch to > Reiser4. > > Ideally, there would be a small set of these plugins demonstrating how to > create a new plugin which operates within the existing disk structure, and > one that extends the on-disk format in a safe way. I second this. I have also spent a considerable amount of time wading through reiser4 code in an attempt to put together a simple plugin. A standalone plugin patch would be invaluable. Look at all the ideas for plugins that have come up on this list, and notice that so far none have come to fruition. > Right now, the cost-of-entry appears to be set too high for developers > outside your team to approach the project. Agreed, after spending weeks on this I am almost at the point of abandoning it.. An example plugin patch (just something trivial) would definitely encourage people to get involved in plugin development. -- Marcus Furlong
Re: Reiser4 unlink performance
Hi Alexander, On Feb 26, 2006, at 13:42, Alexander Zarochentsev wrote: Which kernel version and reiser4 patches were used? 2.6.15.4r4 kernel, reiser4-for-2.6.15-1.patch Is the system SMP? Yes. No, "Flushing like mad" usually indicates a bug. Good to know. Thanks! Alec
Re: possible reiser4 bug
On Sunday 26 February 2006 08:33, Alexander Zarochentsev wrote: > please use better version of the patch (attached). Hello, after some days of testing the problem seems gone. The kernel survived many CPU and I/O intensive tasks (some compilations of gcc and firefox) without an hiccup, whereas without the patch it hanged quite soon. Thanks and regards, Francesco -- Dr. Francesco Biscani Dipartimento di Astronomia Università di Padova [EMAIL PROTECTED]
Re: reiserfs 3 on top of software raid 1
Hello On Tue, 2006-02-28 at 00:14 +0100, Pierre Etchemaïté wrote: > Hi all, > > I have a question that didn't occur to me until a power failure (eh)... > > When a journalized file system like reiserfs 3 runs on top on a > software raid volume, does the volume give enough (and correct) > feedback so that the file system can still guarantee that its metadata > will be in a consistant state after a power failure/crash/you name it ? > > If all disks go back online ? If some don't (but below redundancy > amount, of course) ? > > In short, beside disks resynching, is a fsck also necessary ? > It should not be. I believe that journal replaying on mount is enough. Does your experience contradict that?
