All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Joliet <marcec@gmx.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: Input/output error on newly created file
Date: Fri, 13 May 2016 10:22:04 +0200	[thread overview]
Message-ID: <2373043.nUhu0pE6A3@thetick> (raw)
In-Reply-To: <pan$b1cd$3f36224$2014cb30$68062598@cox.net>

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

Am Friday 13 May 2016
schrieb Duncan <1i5t5.duncan@cox.net>

>Szalma László posted on Thu, 12 May 2016 20:28:24 +0200 as excerpted:
>> The files that rarely become unreadable (I/O error but no error in dmesg
>> or anywhere) are mysql MyIsam database files, and they are always small.
>> Like 16kbyte for example, or smaller. Sometimes dropping the fs cache
>> fixes the problem, sometimes not. Umount / mount always fixes the
>> problem. Scrub says the filesystem is OK (when the file is unreadable).
>
>Is it possible the files are always under 4 KiB?

For the record, I was seeing a similar error with dovecot *.index.log files 
(see the ML thread started by Szalma László) .  In my case they are *not* all 
under 4 KiB.  Looking at some of the affected files, one of them is 25K, and 
another is 6.6K.  However, perhaps they compress to under 4K?  But compressing 
the 25K one with lzop only goes down to 5.6K with -9 :-/ .

>While there's a few variables as to max size, with 4 KiB being the
>practical max, btrfs will inline really small files into their metadata
>node instead of writing them out as 4 KiB data block extents.  Since
>that's obviously a different code-path, if it's only 4 KiB and smaller
>files, it's possible there's a race in that code-path that when lost,
>results in the file "disappearing" without a dmesg trace, only to
>reappear after reboot.
>
>Actually, now that I think about it, if the files are all OVER say 2 KiB
>but still quite small, say under 16 KiB, and if they had just recently
>grown, it's possible that the race is in the transition from the inline
>metadata state to the multiples of 4 KiB block data extent state.
>
>And if all the files had just shrunk, say from compaction (if done in-
>place, not with a copy and rename), perhaps it's the reverse, the
>transition from written data blocks to inline metadata state.

I'm glad somebody is (publicly) thinking about this :-) !

Greetings
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      reply	other threads:[~2016-05-13  8:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-08 22:18 Input/output error on newly created file Nikolaus Rath
2016-05-09 15:46 ` Filipe Manana
2016-05-10  3:29   ` Nikolaus Rath
2016-05-12 15:46     ` Nikolaus Rath
2016-05-12 16:17       ` Diego Calleja
2016-05-12 17:41         ` Nikolaus Rath
2016-05-12 18:28           ` Szalma László
2016-05-13  7:46             ` Duncan
2016-05-13  8:22               ` Marc Joliet [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=2373043.nUhu0pE6A3@thetick \
    --to=marcec@gmx.de \
    --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 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.