I'm setting up a big fileserver here.
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.
>From what I hear, ReiserFS is workin
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
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 or
On Wednesday October 4, [EMAIL PROTECTED] wrote:
> 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
> > >
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 structu
On Thu, Oct 05, 2000 at 01:54:59PM +1100, 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 strip
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 (independently whether it's the xor one or one the
> other one) has
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 d
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
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 sup
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 wa
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
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
16 matches
Mail list logo
