Re: Bad fs performance, IO freezes

["cheater00 ." <cheater00@gmail.com>]

Hi Austin,
seek times are fine, but this literally freezes my computer for a
split second. I've had to re-type this email twice because the freezes
meant letters I typed would not arrive on the screen.
USB disks are so common they should not be having issues.
I have 4.3.0-040300rc7-generic #201510260712 which is just three days old.

Please advise. Isn't it better to *not* use a vm to debug this?
BTW, if we are talking about slow speed making things worse, I could
try downgrading the cable to usb2.
Is there a standard virtualbox VM that I could use?
I'll download Gentoo in the meantime. I have never used it. I'm
getting the "minimal installation cd" from 29th september.
http://distfiles.gentoo.org/releases/x86/autobuilds/20150929/install-x86-minimal-20150929.iso

On Thu, Oct 29, 2015 at 3:00 PM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:
> On 2015-10-29 09:03, cheater00 . wrote:
>>
>> Hi Liu,
>> after talking with Holger I believe turning off COW on this FS will
>> work to alleviate this issue. However, even with COW on, btrfs
>> shouldn't be making my computer freeze every 5 seconds... especially
>> while the disk is written to at mere tens of kilobytes per second.
>> It's not even the disk holding the system. I consider this a pretty
>> bad bug... should we go on with trying to reproduce a minimum case?
>> How would I go about this?
>
>
> Well, COW can cause some pretty unexpected behavior for some use cases.  If
> you have a big disk (I think I remember you saying it was larger than 1TB),
> then COW can cause some pretty significant seek times because of how it
> works.  With the current state of BTRFS, I wouldn't personally consider
> running BTRFS on anything bigger than 256G with a non-zero seek time with
> COW turned on, because large rewrites would have the potential to cause
> horrifically long seek times just for a RMW cycle on a single block, and
> this is in turn part of why database files and virtual-machine images tend
> to be pathological use cases for BTRFS.
>
> I do agree that this kind of thing is a bug, but it's not something that
> causes data corruption, which means that it is slightly lower priority as
> far as most people are concerned.  Reproducing it might be tricky also,
> because I'd be willing to bet that things get better to the point of it
> being almost unnoticeable with an internal disk (USB is horrible when it
> comes to block storage performance, and has all kinds of potential
> reliability issues).
>
> Normally, when I try to go about reproducing something like this, I use a
> virtual machine running the most recent stable version of the Linux kernel,
> usually with a minimalistic Gentoo installation (although a clean install of
> pretty much any distro works fine).  There are a couple of reasons I use
> such a setup:
> 1. Using a clean install provides a well defined initial state, making it
> easier for other people to reproduce any results.
> 2. Using the most recent stable kernel available (usually) eliminates the
> chances of old bugs causing issues.
> 3. Using a VM means that your disk access will be slower, which will visibly
> accentuate any kind of performance issues.
> 4. Using a VM also means that it is very easy to safely generate crash dumps
> and simulate data corruption for testing purposes, and makes it easier to
> experiment with different parameters (for example, UP versus SMP, or
> different amounts of RAM).
>
> If you do decide to go this route, my suggestion would be to use VirtualBox
> unless you have significant experience with some other hypervisor, as it's
> one of the easiest to learn to use (I usually use Xen or QEMU, but both
> require significant effort to set up initially, and are decidedly
> non-trivial to learn), and learning to debug stuff like this is itself not
> an easy task.
>