All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: J - <mailinglists@hotmail.nl>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: BTRFS errors on fresh filesystem
Date: Fri, 28 Aug 2015 11:34:35 -0400	[thread overview]
Message-ID: <55E07F8B.6080705@gmail.com> (raw)
In-Reply-To: <DUB126-W37868A0DCD702A054C464CB46E0@phx.gbl>

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

On 2015-08-28 11:10, J - wrote:
> I have noticed a BTRFS error mentioned in two consecutive identical entries  in my kernel log:
> "BTRFS error (device sda2): bad extent! em: [0 0] passed [0 4096]"
>
> sda2 contains a btrfs with skinny extents has been created a few days ago and contains a few subvolumes (mounted as root and home) and subsubvolumes a few gigabites of data in smallish files. It is mounted with 'rw,relatime,compress-force=lzo,ssd,space_cache',
>
> Shortly after noticing the errors, which cannot have been long after their occurrence, I rebooted and ran 'btrfs check' on the filesystem, with output as follows:
>
> 'Checking filesystem on /dev/sda2
> UUID: c2c63f52-a322-413f-84f6-b4106fdff8c1
> found 16882602001 bytes used err is 0
> total csum bytes: 15775044
> total tree bytes: 610959360
> total fs tree bytes: 563019776
> total extent tree bytes: 28459008
> btree space waste bytes: 85192798
> file data blocks allocated: 19913826304
>   referenced 24478576640
> btrfs-progs v4.1.2'
>
> After this I ran 'btrfs scrub' which reported no errors.
>
> The filesystem has been created (and also checked) with Arch Linux, kernel 4.1.6, btrfs-progs 4.1.2.
> The computer has a AMD FX-8350CPU, 32GB ECC ram, a 990fx chipset and the drive is a OCZ Vector 180 (GPT, 2 partition, ESP from 2048s to 1050623s, .linux partition from 1050624s to 468860175s)
I would suggest some serious testing of that OCZ SSD, they are known to 
have data corruption issues under heavy load or across unclean 
shutdowns, and these issues will cause problems with any filesystem you 
put on it.  Personally I would not trust an OCZ SSD as anything other 
than scratch space for testing, and even then would only do so cautiously.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

      parent reply	other threads:[~2015-08-28 15:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-28 15:10 BTRFS errors on fresh filesystem J -
2015-08-28 15:26 ` Chris Murphy
2015-08-28 15:34 ` Austin S Hemmelgarn [this message]

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=55E07F8B.6080705@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mailinglists@hotmail.nl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.