linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Swâmi Petaramesh" <swami@petaramesh.org>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: REPORT: Still a lot of BTRFS freezes in 3.16.1-1-ARCH
Date: Sun, 24 Aug 2014 19:25:43 +0200	[thread overview]
Message-ID: <4207113.A3bnH6gnWF@zafu> (raw)

Hi there,

This is to report that I'm still having quite systematic BRTFS freezes on an 
ArchLinux running latest 3.16.1-1-ARCH kernel.

Interestingly enough, I have several latops with the exact same setup :

Arch Linux with 3.16.1-1-ARCH kernel, fully running on BTRFS (with LZO 
compression) over LVM over LUKS.

All machines have hourly BTRFS snapshots performed by SuSE « snapper » 
utility.

The difference between the laptops only relate to the disk (HD vs. SSD) and CPU 
"power".

I have :

- Intel Core I3 with mechanical 1TB Samsung HD: NEVER hangs.

- Intel Celeron CPU 1007U @ 1.50GHz with Crucial_512GB MX100 SSD: NEVER hangs.

- Asus EeePC, Intel Atom CPU N450  @ 1.66GHz with SanDisk 120 GB SSD: VERY 
OFTEN HANGS, only since 3.15 kernel, and I'm pretty sure that the hardware 
itself is OK.


It seems that the only machine on which BTRFS crashes is the one on which the 
CPU is weak & slow relatively to the SSD (so the I/O, considering compression 
and encryption, is quite surely CPU-bound).

The typical situation causing a machine crash is : Performing a lot of updates 
using "pacman -Syu".

The typical freeze happens while applying the updates (not while dowloading 
the packages).

The typical result is :

- The update process stalls.
- The rest of the machine AT FIRST seems unaffected
- After a while eventually everything that needs disk access freezes
- A fierce reboot is finally needed.

The typical outcome is :

- After reboot, a number of files belonging to the packages that were in 
process of updating, or had been updated last, appear as having a size of ZERO 
bytes (so what depends on them is typicaly broken).

(If the write to disk is ORDERED, this isn't supposed to happen, is it ??)

- Forcibly reinstalling the packages for the broken files usually fixes things 
up.

I've had this exact experience at least 5 times on this machine now, always 
exactly as described.

I've never seen any such issue on my other machines on which CPU power is 
better relatively to the disk speed...

Hope this can be of any help ?

I'm longing for a kernel fix cause I fear something could seriously break in 
the end...

Kind regards.

-- 
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E


             reply	other threads:[~2014-08-24 17:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-24 17:25 Swâmi Petaramesh [this message]
2014-08-24 17:32 ` REPORT: Still a lot of BTRFS freezes in 3.16.1-1-ARCH Tomasz Torcz
2014-08-25  4:03   ` Liu Bo
2014-08-25  4:04     ` Liu Bo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4207113.A3bnH6gnWF@zafu \
    --to=swami@petaramesh.org \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).