On Thu, 5 Oct 2000, Neil Brown wrote:
> 2/ Arrange your filesystem so that you write new data to an otherwise
>unused stripe a whole stripe at a time, and store some sort of
>chechksum in the stripe so that corruption can be detected. This
>implies a log structured filesystem
On Thu, 5 Oct 2000, Neil Brown wrote:
2/ Arrange your filesystem so that you write new data to an otherwise
unused stripe a whole stripe at a time, and store some sort of
chechksum in the stripe so that corruption can be detected. This
implies a log structured filesystem (though
Jeremy Fitzhardinge wrote:
>
> On Thu, Oct 05, 2000 at 11:33:30AM +0200, Helge Hafting wrote:
> > A power failure might leave you with a corrupt disk block. That is
> > detectable (read failure) and you may then reconstruct it using the
> > rest of the stripe. This will get you data from
On Friday October 6, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
> > Suppose, for stripe X the parity device is device 1 and we were
> > updating the block on device 0 at the time of system failure.
> > What had happened was that the new parity block was written out, but
> > the new data block
Neil Brown wrote:
> Suppose, for stripe X the parity device is device 1 and we were
> updating the block on device 0 at the time of system failure.
> What had happened was that the new parity block was written out, but
> the new data block wasn't.
> Suppose further than when the system come back,
On Friday October 6, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
Suppose, for stripe X the parity device is device 1 and we were
updating the block on device 0 at the time of system failure.
What had happened was that the new parity block was written out, but
the new data block wasn't.
Jeremy Fitzhardinge wrote:
On Thu, Oct 05, 2000 at 11:33:30AM +0200, Helge Hafting wrote:
A power failure might leave you with a corrupt disk block. That is
detectable (read failure) and you may then reconstruct it using the
rest of the stripe. This will get you data from either before
On Thu, Oct 05, 2000 at 11:33:30AM +0200, Helge Hafting wrote:
> A power failure might leave you with a corrupt disk block. That is
> detectable (read failure) and you may then reconstruct it using the
> rest of the stripe. This will get you data from either before
> or after the update was
Neil Brown wrote:
>
> For RAID5 a 'stripe' is a set of blocks, one from each underlying
> device, which are all at the same offset within their device.
> For each stripe, one of the blocks is a "parity" block - though it is
> a different block for each stripe (parity is rotated).
>
> Content of
Vojtech Pavlik wrote:
> Hmm, now that I think about it, this can be brought to data corruption
> even easier ... Imagine a case where a stripe isn't written completely.
> One of the drives (independently whether it's the xor one or one the
> other one) has thus invalid data.
>
> Now how do you
On Thu, Oct 05, 2000 at 09:49:29AM +0200, Andi Kleen wrote:
> On Thu, Oct 05, 2000 at 09:39:34AM +0200, Vojtech Pavlik wrote:
> > Hmm, now that I think about it, this can be brought to data corruption
> > even easier ... Imagine a case where a stripe isn't written completely.
> > One of the
On Thu, Oct 05, 2000 at 01:54:59PM +1100, Neil Brown wrote:
> 2/ Arrange your filesystem so that you write new data to an otherwise
>unused stripe a whole stripe at a time, and store some sort of
>chechksum in the stripe so that corruption can be detected. This
>implies a log
On Thu, Oct 05, 2000 at 01:54:59PM +1100, Neil Brown wrote:
2/ Arrange your filesystem so that you write new data to an otherwise
unused stripe a whole stripe at a time, and store some sort of
chechksum in the stripe so that corruption can be detected. This
implies a log structured
On Thu, Oct 05, 2000 at 09:49:29AM +0200, Andi Kleen wrote:
On Thu, Oct 05, 2000 at 09:39:34AM +0200, Vojtech Pavlik wrote:
Hmm, now that I think about it, this can be brought to data corruption
even easier ... Imagine a case where a stripe isn't written completely.
One of the drives
Vojtech Pavlik wrote:
Hmm, now that I think about it, this can be brought to data corruption
even easier ... Imagine a case where a stripe isn't written completely.
One of the drives (independently whether it's the xor one or one the
other one) has thus invalid data.
Now how do you
Neil Brown wrote:
For RAID5 a 'stripe' is a set of blocks, one from each underlying
device, which are all at the same offset within their device.
For each stripe, one of the blocks is a "parity" block - though it is
a different block for each stripe (parity is rotated).
Content of the
On Thu, Oct 05, 2000 at 11:33:30AM +0200, Helge Hafting wrote:
A power failure might leave you with a corrupt disk block. That is
detectable (read failure) and you may then reconstruct it using the
rest of the stripe. This will get you data from either before
or after the update was
Andi Kleen wrote:
> On Wed, Oct 04, 2000 at 01:42:46AM -0600, Andreas Dilger wrote:
> > You should ask the reiserfs mailing list for outstanding problems. As
> > far as LVM is concerned, I don't think there is a problem, but watch out
> > for software RAID 5 and journalling filesystems (reiser
On Wed, Oct 04, 2000 at 01:42:46AM -0600, Andreas Dilger wrote:
> Magnus Naeslund writes:
> > The storage will be exported via ftp, samba, nfs & cvs.
> > I will patch the selected kernel to support LFS and LVM, and the filesystem
> > will run on that.
> >
> > I am very interested in ReiserFS,
Magnus Naeslund writes:
> The storage will be exported via ftp, samba, nfs & cvs.
> I will patch the selected kernel to support LFS and LVM, and the filesystem
> will run on that.
>
> I am very interested in ReiserFS, and success/failure stories about it.
You really need to watch out when using
Magnus Naeslund writes:
The storage will be exported via ftp, samba, nfs cvs.
I will patch the selected kernel to support LFS and LVM, and the filesystem
will run on that.
I am very interested in ReiserFS, and success/failure stories about it.
You really need to watch out when using
On Wed, Oct 04, 2000 at 01:42:46AM -0600, Andreas Dilger wrote:
Magnus Naeslund writes:
The storage will be exported via ftp, samba, nfs cvs.
I will patch the selected kernel to support LFS and LVM, and the filesystem
will run on that.
I am very interested in ReiserFS, and
22 matches
Mail list logo
