linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: dsterba@suse.cz, Marc Dietrich <marvin24@gmx.de>,
	linux-btrfs@vger.kernel.org
Subject: Re: FIBMAP unsupported
Date: Thu, 2 Oct 2014 18:39:32 +0100	[thread overview]
Message-ID: <20141002173932.GA30783@carfax.org.uk> (raw)
In-Reply-To: <20141002172549.GV11436@twin.jikos.cz>

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

On Thu, Oct 02, 2014 at 07:25:49PM +0200, David Sterba wrote:
> On Thu, Oct 02, 2014 at 05:13:22PM +0200, Marc Dietrich wrote:
> > I have a large (25G) virtual disk on a btrfs fs. Yes, I know this is not 
> > optimial. So I try to defrag it from time to time. However, using "btrfs fi 
> > defrag -c vm.vdi" results in even more fragments than before (reported by 
> > filefrag). So I wrote my own pseudo defragger,
> 
> Unfortunatelly the default target fragment size is 256k. Try
> 'btrfs filesystem defrag -t 32m ...' or higher numbers and see if it
> helps.

   Note also that a compressed file will have fragments on the scale
of about 128k reported by filefrag, because of the way that the
compression works. The file may actually be contiguous, but filefrag
won't know about it. (At least, that's historically been the case. I
don't know if filefrag has recently grown some extra knowledge of
compressed extents.)

   Hugo.

> > which produces much better results (ok, the file must not be in use). 
> > Somewhere in the 3.17 cycle the resulting image got corrupted using the script 
> > above. 
> > 
> > Running filefrag on it returns "FIBMAP unsupported".
> 
> This message doe not mean it is a corruption, but filefrag tries to use
> the FIBMAP ioctl that is not implemented on btrfs, instead FIEMAP is
> used.
> 
> filefrag on a nocow file works for me here (3.16.x kernel), I can see
> that filefrag on a directory prints the FIBMAP message.
> 
> > Virtualbox returns  "AHCI#0P0: Read at offset 606236672 (49152 bytes left) 
> > returned rc=VERR_DEV_IO_ERROR". No errors in the kernel log.
> > 
> > Trying "cp vm.vdi /dev/null" returns: cp: Error reading „vm.vdi“: IO-Error
> 
> This could be caused by the virtualization layer. Try to run scrub and
> fsck in the non-destru^Wchecking mode if it finds problems.
> 
> As you're using compression and autodefrag, a quick skim of the 3.17
> patches points to e9512d72e8e61c750c90efacd720abe3c4569822 "fix
> autodefrag with compression", but that's just "keyword" match.
> 
> There's another report about nocow corruption and VirtualBox in a 3.16 +
> for-linus version (which is almost 3.17-rc)
> http://article.gmane.org/gmane.comp.file-systems.btrfs/38701/
> 
> But according to the attached messages, the underlying device is
> unreliable and logs a lot of IO errors.
> 
> For now it looks like VirutalBox is not writing the data or there is a
> bug introduced post 3.16 killing nocow files.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
          --- ...  one ping(1) to rule them all, and in the ---          
                         darkness bind(2) them.                          

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

  reply	other threads:[~2014-10-02 17:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-02 15:13 FIBMAP unsupported Marc Dietrich
2014-10-02 17:25 ` David Sterba
2014-10-02 17:39   ` Hugo Mills [this message]
2014-10-02 19:55   ` Marc Dietrich
2014-10-02 22:11     ` Marc Dietrich
2014-10-03 13:15       ` Filipe Manana
2014-10-04 21:33         ` Marc Dietrich

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=20141002173932.GA30783@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=marvin24@gmx.de \
    /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).