On 17:11 Tue 22 Aug , Andrew Morton wrote:
>
> I can see that the bigalloc code as-is is pretty sad, but this is a scary
> patch. It has the potential to cause people significant performance
> problems way, way ahead in the future.
>
> For example, suppose userspace is growing two files conc
The bonus to you is that if anyone
tries to drag out issues after you've done the list, you can point
to the it and say "These were the limit of the real issues that
were raised. Anything beyond is someone else's preference, and
therefore their job to get included."
--Clay
On
I like using a term that is already in an accepted part of the
kernel. Extensions might smack of plugins a bit much, and we're
trying to avoid just doing a s/plugins/extensions/ of the
arguments we're seeing now.
--Clay
On 18:22 Sat 05 Aug , Maciej Sołtysiak wrote:
> > So we're talking about
On 20:42 Mon 31 Jul , Alan Cox wrote:
> Ar Llu, 2006-07-31 am 12:17 -0700, ysgrifennodd Clay Barnes:
> > Of course, if ext3 were proven to be more robust against failures, I bet
> > the reiser team would be very interested in all the forensic data you
> > can offer, since
On 20:43 Mon 31 Jul , Jan-Benedict Glaw wrote:
> On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree <[EMAIL PROTECTED]> wrote:
> > Jan-Benedict Glaw schrieb am 2006-07-31:
> > > * reiser3: A HDD containing a reiser3 filesystem was tried to be
> > > booted on a machine that fucked up DMA w
On 02:26 Thu 20 Jul , Andreas Dilger wrote:
> On Jul 19, 2006 16:57 +0400, Alexander Zarochentsev wrote:
> > On Wednesday 19 July 2006 16:10, Mark F wrote:
> > > I've tried to create a large 5TB file system using both reiserfs and
> > > ext3 and both have failed.
> >
> > you might need to con
I have been thinking lately that though we certainly need to do
cleanup of the various bugs and such relating to the storage layer,
perhaps now is a good time to review and discuss the plans for the
semantic layer so that any outstanding concerns can be thouroughly
discussed and resolved before we
tools like inotify
FUSE and Lucene to implement their design, instead of writing a bunch of
redundant code and their interest in backwards compadability through a
virtual FS---it has the chance to bring non-heriarchical storage to
some, but it lacks the careful planning that has gone into the
discussion of the metadata plugin I've seen on the mailing list alone.
--Clay Barnes
On 16:11 Tue 11 Jul , Hans Reiser wrote:
> Clay Barnes wrote:
> >On 15:04 Tue 11 Jul , Hans Reiser wrote:
> >>6) optimize fsync --- substantive task which requires using fixed area
> >>for write twice logging, and using write twice logging for fsync'd
>
On 15:04 Tue 11 Jul , Hans Reiser wrote:
> Please feel free to comment on this list and the order of its tasks:
>
> 0) fix all bugs as they arise
>
> 1) get batch_write into the -mm kernel --- small task
>
> 2) get read optimization code into the -mm kernel (coded and probably
> debugged but
On 12:25 Tue 06 Jun , Hans Reiser wrote:
> Clay Barnes wrote:
>
> >On 18:38 Tue 06 Jun , Vladimir V. Saveliev wrote:
> >
> >
> >>Hello
> >>
> >>On Tue, 2006-06-06 at 09:44 -0400, Tom Vier wrote:
> >>
> &
On 18:38 Tue 06 Jun , Vladimir V. Saveliev wrote:
> Hello
>
> On Tue, 2006-06-06 at 09:44 -0400, Tom Vier wrote:
> > On Tue, May 23, 2006 at 11:51:02AM -0400, Tom Vier wrote:
> > > It seems that both r4 and xfs allow a large number of pages to be dirtied,
> > > before queuing them for writebac
To amplify what Hans (accurately) wrote, once you see bad sectors, that
means that you already have many more than you see, and that your hard
drive is all out of spare sectors to silently swap out for when it finds
one.
Basically, there's so much wrong with the surface that your hard drive
c
ssed) from source/text files
(excellent compression). A rough estimate from someone's experience
using on mixed files it would help.
Also: Is the algorithm set in stone? If so what is it? If not, what
is it now/expected to be?
Thanks,
Clay Barnes
14 matches
Mail list logo
