[EMAIL PROTECTED] said:
> Unless someone fixed it recently, when jffs was ported to 2.4, it
> lost the ability to run on block devices and can currently only
> operate via the mtd layer. In the 2.0.x kernels, it could target block
> devices.
> For things like disk-on-module (ide flash disks)
Hi,
On Mon, Oct 02, 2000 at 03:13:07AM +0200, Daniel Phillips wrote:
> What I've seen proposed is a mechanism where the VM can say 'flush this
> page' to a filesystem and the filesystem can then go ahead and do what
> it wants, including flushing the page, flushing some other page, or not
>
Hi,
On Mon, Oct 02, 2000 at 03:13:07AM +0200, Daniel Phillips wrote:
What I've seen proposed is a mechanism where the VM can say 'flush this
page' to a filesystem and the filesystem can then go ahead and do what
it wants, including flushing the page, flushing some other page, or not
doing
Andreas Dilger wrote in part:
>
> Albert Cahalan write:
> > The nice way to develop this code is with a block device that
> > discards all writes after a timer goes off.
This is nice, but a bit destructive for my likes. Hard and long to
do multiple tests. Also, it misses one severe case: an
Ralf Baechle wrote:
>
> On Sun, Oct 01, 2000 at 10:21:34AM -0500, Robert Redelmeier wrote:
> > You boys and girls don't try this at home on Linux! The ext2 fsck is horrible
> > after a powerfail, and I've lost superblocks and had to re-install :( .
>
> There is actually some indication that
On Sun, Oct 01, 2000 at 10:21:34AM -0500, Robert Redelmeier wrote:
> As an experiment, I pulled the plug towards the end of 5 FreeBSD kernel
> compiles (SMP `make -j4`). In all cases, the fsck upon restart was minor,
> just freeing inodes. In four of the cases, `make` just picked up where
>
Albert Cahalan write:
> Robert Redelmeier writes:
> > Daniel Phillips wrote in part:
>
> >> One thing to keep in mind in all of this is: nobody is testing the
> >> reliability of their journalling or any other kind of filesystem just by
> >> running it. To test these things you have to
Andi Kleen wrote:
>
> On Mon, Oct 02, 2000 at 03:33:54PM +0200, Daniel Phillips wrote:
> > The tricky part of the crash simulator would be recovering the resources
> > the filesystem was using and convincing the VFS to let go of the the
> > partition. If you could return the system to a stable
On Mon, Oct 02, 2000 at 03:33:54PM +0200, Daniel Phillips wrote:
> The tricky part of the crash simulator would be recovering the resources
> the filesystem was using and convincing the VFS to let go of the the
> partition. If you could return the system to a stable state you could
> do many,
"Albert D. Cahalan" wrote:
>
> Robert Redelmeier writes:
> > Daniel Phillips wrote in part:
>
> >> One thing to keep in mind in all of this is: nobody is testing the
> >> reliability of their journalling or any other kind of filesystem just by
> >> running it. To test these things you have to
"Albert D. Cahalan" wrote:
Robert Redelmeier writes:
Daniel Phillips wrote in part:
One thing to keep in mind in all of this is: nobody is testing the
reliability of their journalling or any other kind of filesystem just by
running it. To test these things you have to
On Mon, Oct 02, 2000 at 03:33:54PM +0200, Daniel Phillips wrote:
The tricky part of the crash simulator would be recovering the resources
the filesystem was using and convincing the VFS to let go of the the
partition. If you could return the system to a stable state you could
do many, many
Andi Kleen wrote:
On Mon, Oct 02, 2000 at 03:33:54PM +0200, Daniel Phillips wrote:
The tricky part of the crash simulator would be recovering the resources
the filesystem was using and convincing the VFS to let go of the the
partition. If you could return the system to a stable state
Albert Cahalan write:
Robert Redelmeier writes:
Daniel Phillips wrote in part:
One thing to keep in mind in all of this is: nobody is testing the
reliability of their journalling or any other kind of filesystem just by
running it. To test these things you have to crash/interrupt the
Ralf Baechle wrote:
On Sun, Oct 01, 2000 at 10:21:34AM -0500, Robert Redelmeier wrote:
You boys and girls don't try this at home on Linux! The ext2 fsck is horrible
after a powerfail, and I've lost superblocks and had to re-install :( .
There is actually some indication that part of the
Andreas Dilger wrote in part:
Albert Cahalan write:
The nice way to develop this code is with a block device that
discards all writes after a timer goes off.
This is nice, but a bit destructive for my likes. Hard and long to
do multiple tests. Also, it misses one severe case: an inode
Robert Redelmeier writes:
> Daniel Phillips wrote in part:
>> One thing to keep in mind in all of this is: nobody is testing the
>> reliability of their journalling or any other kind of filesystem just by
>> running it. To test these things you have to crash/interrupt the system
>> *a lot*.
Daniel Phillips wrote in part:
>
> To be fair, when Soft Updates is working perfectly you will move from a
> situation where you are constantly at risk of catstrophic filesystem
> damage to one where you will just be losing track of some free blocks,
> have some file lengths wrong, and some
Rik van Riel wrote:
>
> On Mon, 2 Oct 2000, Daniel Phillips wrote:
> > Rik van Riel wrote:
> > >
> > > Local mechanisms simply CANNOT make page replacement work
> > > well on a system-wide level.
> >
> > I think you mean 'local mechanisms alone'. The question is not
> > *whether* the subsystems
On Mon, 2 Oct 2000, Daniel Phillips wrote:
> Rik van Riel wrote:
> >
> > Local mechanisms simply CANNOT make page replacement work
> > well on a system-wide level.
>
> I think you mean 'local mechanisms alone'. The question is not
> *whether* the subsystems will work together, but *how*.
Now
Rik van Riel wrote:
>
> Local mechanisms simply CANNOT make page replacement work
> well on a system-wide level.
I think you mean 'local mechanisms alone'. The question is not
*whether* the subsystems will work together, but *how*. I have a
nagging feeling we can do a little better than the
On Mon, 2 Oct 2000, Daniel Phillips wrote:
> Rik van Riel wrote:
> > On Sun, 1 Oct 2000, bert hubert wrote:
> > >
> > > If Rik gets some kind of memory pressure callback API in the
> > > kernel, there is no theoretical reasons why the journalling
> > > filesystems couldn't be merged safely.
> >
On Sun, 1 Oct 2000, bert hubert wrote:
> On Sun, Oct 01, 2000 at 03:39:51PM +, Christoph Hellwig wrote:
> > Robert Redelmeier <[EMAIL PROTECTED]> wrote:
> > > I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
> > > to Linux
On Sun, 1 Oct 2000, Alan Cox wrote:
> > I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
> > to Linux in 2.5 ??? Kirk has recently modified his licence (friendlier).
> > I could only find some noncomittal postings on LKML from
Robert Redelmeier wrote:
> I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
> to Linux in 2.5 ??? Kirk has recently modified his licence (friendlier).
> I could only find some noncomittal postings on LKML from 1997.
>
> S-U brings consider
Billy Harvey wrote:
>
> [EMAIL PROTECTED]:
> > I think everyone is planning to go the whole way - that is to use full
> > journalled file systems - reiserfs, ext3, xfs, jffs, ibm jfs, .. whatever
>
> Is tux2 looking like a built-in possibility soon?
Gack, no. I hope to give it to myself as
On Sun Oct 01, 2000 at 04:54:05PM +0100, Alan Cox wrote:
> > What of those journalled file systems are more prominent to success 2.5.
>
> jffs is in 2.4 (but its a log structured fs for flash memory not generic)
> ext3 and reiserfs are both being used in production boxes as add ons
Unless
On 2000-10-01T11:50:10,
Ernesto Vargas <[EMAIL PROTECTED]> said:
> What of those journalled file systems are more prominent to success 2.5.
ext3 is stable on my laptop.
reiserfs is stable at SuSE on a 250 GB RAID with 2.2 million files.
XFS has IMHO the best chance to surpass both in
> What of those journalled file systems are more prominent to success 2.5.
jffs is in 2.4 (but its a log structured fs for flash memory not generic)
ext3 and reiserfs are both being used in production boxes as add ons
Alan
-
To unsubscribe from this list: send the line "unsubscribe
What of those journalled file systems are more prominent to success 2.5.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Alan Cox
Sent: Sunday, October 01, 2000 11:28 AM
To: Robert Redelmeier
Cc: [EMAIL PROTECTED]
Subject: Re: Soft-Updates for Linux
On Sun, Oct 01, 2000 at 03:39:51PM +, Christoph Hellwig wrote:
> Robert Redelmeier <[EMAIL PROTECTED]> wrote:
> > I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
> > to Linux in 2.5 ??? Kirk has recently modified his licence (fri
Robert Redelmeier <[EMAIL PROTECTED]> wrote:
> I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
> to Linux in 2.5 ??? Kirk has recently modified his licence (friendlier).
> I could only find some noncomittal postings on LKML from 1997.
[EMAIL PROTECTED]:
> I think everyone is planning to go the whole way - that is to use full
> journalled file systems - reiserfs, ext3, xfs, jffs, ibm jfs, .. whatever
Is tux2 looking like a built-in possibility soon?
Billy
-
To unsubscribe from this list: send the line "unsubscribe
> I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
> to Linux in 2.5 ??? Kirk has recently modified his licence (friendlier).
> I could only find some noncomittal postings on LKML from 1997.
I think everyone is planning to go the whole way -
I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
to Linux in 2.5 ??? Kirk has recently modified his licence (friendlier).
I could only find some noncomittal postings on LKML from 1997.
S-U brings considerable benefits akin to JFS for crash protection to *BS
I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
to Linux in 2.5 ??? Kirk has recently modified his licence (friendlier).
I could only find some noncomittal postings on LKML from 1997.
S-U brings considerable benefits akin to JFS for crash protection to *BS
I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
to Linux in 2.5 ??? Kirk has recently modified his licence (friendlier).
I could only find some noncomittal postings on LKML from 1997.
I think everyone is planning to go the whole way - that is t
[EMAIL PROTECTED]:
I think everyone is planning to go the whole way - that is to use full
journalled file systems - reiserfs, ext3, xfs, jffs, ibm jfs, .. whatever
Is tux2 looking like a built-in possibility soon?
Billy
-
To unsubscribe from this list: send the line "unsubscribe
Robert Redelmeier [EMAIL PROTECTED] wrote:
I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
to Linux in 2.5 ??? Kirk has recently modified his licence (friendlier).
I could only find some noncomittal postings on LKML from 1997.
I doubt. Ther
On Sun, Oct 01, 2000 at 03:39:51PM +, Christoph Hellwig wrote:
Robert Redelmeier [EMAIL PROTECTED] wrote:
I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
to Linux in 2.5 ??? Kirk has recently modified his licence (friendlier).
I could only
What of those journalled file systems are more prominent to success 2.5.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Alan Cox
Sent: Sunday, October 01, 2000 11:28 AM
To: Robert Redelmeier
Cc: [EMAIL PROTECTED]
Subject: Re: Soft-Updates for Linux
What of those journalled file systems are more prominent to success 2.5.
jffs is in 2.4 (but its a log structured fs for flash memory not generic)
ext3 and reiserfs are both being used in production boxes as add ons
Alan
-
To unsubscribe from this list: send the line "unsubscribe
On 2000-10-01T11:50:10,
Ernesto Vargas [EMAIL PROTECTED] said:
What of those journalled file systems are more prominent to success 2.5.
ext3 is stable on my laptop.
reiserfs is stable at SuSE on a 250 GB RAID with 2.2 million files.
XFS has IMHO the best chance to surpass both in server
On Sun Oct 01, 2000 at 04:54:05PM +0100, Alan Cox wrote:
What of those journalled file systems are more prominent to success 2.5.
jffs is in 2.4 (but its a log structured fs for flash memory not generic)
ext3 and reiserfs are both being used in production boxes as add ons
Unless someone
Billy Harvey wrote:
[EMAIL PROTECTED]:
I think everyone is planning to go the whole way - that is to use full
journalled file systems - reiserfs, ext3, xfs, jffs, ibm jfs, .. whatever
Is tux2 looking like a built-in possibility soon?
Gack, no. I hope to give it to myself as a
Robert Redelmeier wrote:
I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
to Linux in 2.5 ??? Kirk has recently modified his licence (friendlier).
I could only find some noncomittal postings on LKML from 1997.
S-U brings considerable benefits a
On Sun, 1 Oct 2000, Alan Cox wrote:
I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
to Linux in 2.5 ??? Kirk has recently modified his licence (friendlier).
I could only find some noncomittal postings on LKML from 1997.
I think everyone is plan
On Sun, 1 Oct 2000, bert hubert wrote:
On Sun, Oct 01, 2000 at 03:39:51PM +, Christoph Hellwig wrote:
Robert Redelmeier [EMAIL PROTECTED] wrote:
I'm wondering if there are any plans to bring Kirk McKusick's "Soft-Updates"
to Linux in 2.5 ??? Kirk has recently modified h
Rik van Riel wrote:
Local mechanisms simply CANNOT make page replacement work
well on a system-wide level.
I think you mean 'local mechanisms alone'. The question is not
*whether* the subsystems will work together, but *how*. I have a
nagging feeling we can do a little better than the
Rik van Riel wrote:
On Mon, 2 Oct 2000, Daniel Phillips wrote:
Rik van Riel wrote:
Local mechanisms simply CANNOT make page replacement work
well on a system-wide level.
I think you mean 'local mechanisms alone'. The question is not
*whether* the subsystems will work
Daniel Phillips wrote in part:
To be fair, when Soft Updates is working perfectly you will move from a
situation where you are constantly at risk of catstrophic filesystem
damage to one where you will just be losing track of some free blocks,
have some file lengths wrong, and some partly
51 matches
Mail list logo
