On May 15, 2013, Josef Bacik wrote:
> So this should only happen in the case that you are on a dm device it looks
> like, is that how you are running?
That was my first thought, but no, I'm using partitions out of the SATA
disks directly. I even checked for stray dm out of fake raid or
somesuch
On May 14, 2013, Liu Bo wrote:
>> In one of the failures that caused machine load spikes, I tried to
>> collect info on active processes with perf top and SysRq-T, but nothing
>> there seemed to explain the spike. Thoughts on how to figure out what's
>> causing this?
> Although I've seen your s
On Sat, May 11, 2013 at 01:16:38AM -0600, Alexandre Oliva wrote:
> On Apr 4, 2013, Alexandre Oliva wrote:
>
> > I've been trying to figure out the btrfs I/O stack to try to understand
> > why, sometimes (but not always), after a failure to read a (data
> > non-replicated) block from the disk, th
On Thu, Apr 04, 2013 at 01:10:27PM -0300, Alexandre Oliva wrote:
> I've been trying to figure out the btrfs I/O stack to try to understand
> why, sometimes (but not always), after a failure to read a (data
> non-replicated) block from the disk, the file being accessed becomes
> permanently locked,
On Apr 4, 2013, Alexandre Oliva wrote:
> I've been trying to figure out the btrfs I/O stack to try to understand
> why, sometimes (but not always), after a failure to read a (data
> non-replicated) block from the disk, the file being accessed becomes
> permanently locked, and the filesystem, unm
I've been trying to figure out the btrfs I/O stack to try to understand
why, sometimes (but not always), after a failure to read a (data
non-replicated) block from the disk, the file being accessed becomes
permanently locked, and the filesystem, unmountable.
Sometimes (but not always) it's possibl
