disk crashes provoked by tahoe-lafs?

[Paul Rabahy]

I don't care what you do, if a program operating in userspace can kill a
disk, I would call that a hardware problem. Even if the hardware didn't
want to claim the problem then the filesystem should be responsible for it.

My honest guess is that you were just hit with a string of bad luck. Were
the drives that failed the same make/model/manufacture date?


On Mon, Apr 14, 2014 at 9:58 PM, Daira Hopwood <daira at jacaranda.org> wrote:

> On 15/04/14 01:34, Greg Troxel wrote:
> >
> > I run tahoe servers on 4 systems in a private grid.  The grid is not
> > used much, but I run deep-check --repair --add-lease every week or so,
> > when I remember.  The nodes all have lease expiration turned on, but are
> > quite unfull.  All are running NetBSD, some -5, some -6.  I do not have
> > these filesystems mounted noatime.
> >
> > 3 of these nodes are physical machines, with 3 kinds of disks.  All have
> > turned up bad blocks.  The 4th is a Xen domU; the dom0 is RAID-1.  One
> > of the dom0's disks also had some bad blocks.  This is a notable
> > cluster; disk failures are otherwise relatively rare.
> >
> > So I really wonder if the lease checking code, or something, is churning
> > the disk.
> >
> > Has anyone else seen this?
>
> 'tahoe deep-check --repair --add-lease' will write to the header of
> every share.
>
> --
> Daira Hopwood ⚥
>
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20140414/ff0d086e/attachment.html>