All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kent Overstreet <kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Brad Campbell <lists2009-+nnirC7rrGZibQn6LdNjmg@public.gmane.org>
Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Bcache explodes when trying to attach
Date: Mon, 17 Oct 2011 21:48:53 -0700	[thread overview]
Message-ID: <20111018044853.GA11435@moria> (raw)
In-Reply-To: <4E9C330C.6090801-+nnirC7rrGZibQn6LdNjmg@public.gmane.org>

Heh. I need to document stuff and change various defaults...

The open is O_DIRECT and the read is 512 bytes - it's failing because
it's smaller than the hardware sector size of the bcache device.

The block size you specify when you format the backing device gets
exported as the hardware sector size; the reason for that is to support
SSDs that have hardware sector sizes > 1 sector.

It can't just use the SSD's hw sector size directly because you could
bring up a bcache device in passthrough mode, attach a cache later
and... boom, you can't change that at runtime.

However, if you rerun make-bcache on the backing device with
--block-size 512, you shouldn't lose any data, you'll just have to
reattach it to the cache set (so make sure it's not in writeback mode
first).

On Mon, Oct 17, 2011 at 09:52:12PM +0800, Brad Campbell wrote:
> On 16/10/11 13:38, Kent Overstreet wrote:
> >Ah, that's good to know. In that case - if you wanted to try it
> >without md - I don't _expect_ any issues, but then that's the point :)
> >
> >Performance numbers would be awesome, if you got that far...
> 
> I've bumped up against another roadblock that puzzles me. Any
> insight would be much appreciated.
> 
> qemu fails to read from the device properly if it's opened with
> O_DIRECT on a bcache based block device.
> 
> If I just use ext4 on a normal partition it works fine.
> 
> Here are a couple of straces. Command lines are identical
> s/raid10/mnt/ for the second one. Both partitions contents are bit
> for bit identical rsync clones. Both ext4 and mounted with the same
> options. These were captured less than a minute apart, so for all
> intents and purposes they represent precisely the failure I'm
> seeing.
> 
> Failing on /dev/bcache0
> 
> 29169 open("/raid10/VM/ubuntu_10.04LTS-zimbra.qcow2",
> O_RDONLY|O_NONBLOCK) = 9
> 29169 ioctl(9, CDROM_DRIVE_STATUS, 0x7fffffff) = -1 ENOTTY
> (Inappropriate ioctl for device)
> 29169 close(9)                          = 0
> 29169 open("/raid10/VM/ubuntu_10.04LTS-zimbra.qcow2",
> O_RDONLY|O_NONBLOCK) = 9
> 29169 ioctl(9, FDGETPRM, 0x7fff9a7cb9e0) = -1 ENOTTY (Inappropriate
> ioctl for device)
> 29169 close(9)                          = 0
> 29169 stat("/raid10/VM/ubuntu_10.04LTS-zimbra.qcow2",
> {st_mode=S_IFREG|0666, st_size=2058485760, ...}) = 0
> 29169 open("/raid10/VM/ubuntu_10.04LTS-zimbra.qcow2",
> O_RDWR|O_DIRECT|O_CLOEXEC) = 9
> 29169 mmap(NULL, 139264, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3dea33000
> 29169 rt_sigprocmask(SIG_BLOCK, [USR2], NULL, 8) = 0
> 29169 signalfd(4294967295, [USR2], 8)   = 10
> 29169 fcntl(10, F_GETFD)                = 0
> 29169 fcntl(10, F_SETFD, FD_CLOEXEC)    = 0
> 29169 fcntl(10, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
> 29169 lseek(9, 0, SEEK_END)             = 2058485760
> 29169 pread(9, 0x7fa3dea34000, 512, 0)  = -1 EINVAL (Invalid argument)
> 29169 close(9)                          = 0
> 
> Working on /dev/sdg4
> 
> 16269 open("/mnt/VM/ubuntu_10.04LTS-zimbra.qcow2", O_RDONLY|O_NONBLOCK) = 9
> 16269 ioctl(9, CDROM_DRIVE_STATUS, 0x7fffffff) = -1 ENOTTY
> (Inappropriate ioctl for device)
> 16269 close(9)                          = 0
> 16269 open("/mnt/VM/ubuntu_10.04LTS-zimbra.qcow2", O_RDONLY|O_NONBLOCK) = 9
> 16269 ioctl(9, FDGETPRM, 0x7fff8a3b1a40) = -1 ENOTTY (Inappropriate
> ioctl for device)
> 16269 close(9)                          = 0
> 16269 stat("/mnt/VM/ubuntu_10.04LTS-zimbra.qcow2",
> {st_mode=S_IFREG|0664, st_size=2058485760, ...}) = 0
> 16269 open("/mnt/VM/ubuntu_10.04LTS-zimbra.qcow2",
> O_RDWR|O_DIRECT|O_CLOEXEC) = 9
> 16269 mmap(NULL, 139264, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc626a46000
> 16269 rt_sigprocmask(SIG_BLOCK, [USR2], NULL, 8) = 0
> 16269 signalfd(4294967295, [USR2], 8)   = 10
> 16269 fcntl(10, F_GETFD)                = 0
> 16269 fcntl(10, F_SETFD, FD_CLOEXEC)    = 0
> 16269 fcntl(10, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
> 16269 lseek(9, 0, SEEK_END)             = 2058485760
> 16269 pread(9, "QFI\373\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\0\0\0\5\0\0\0\0"...,
> 512, 0) = 512
> 16269 pread(9, "\200\0\0\0\0\4\0\0\200\0\0\0\4&\0\0\200\0\0\0\4\205\0\0\0\0\0\0\0\0\0\0"...,
> 512, 196608) = 512
> 

      parent reply	other threads:[~2011-10-18  4:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-15  5:43 Bcache explodes when trying to attach Brad Campbell
     [not found] ` <4E991D90.1040008-+nnirC7rrGZibQn6LdNjmg@public.gmane.org>
2011-10-15 12:59   ` Brad Campbell
     [not found]     ` <4E9983B1.9060803-+nnirC7rrGZibQn6LdNjmg@public.gmane.org>
2011-10-16  5:08       ` Kent Overstreet
     [not found]         ` <CAC7rs0sm5BgEawAZYjJjnrqAgyK+D96vmpn=1NEQuTJGk+BgAg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-10-16  5:15           ` Brad Campbell
     [not found]             ` <4E9A6866.70803-+nnirC7rrGZibQn6LdNjmg@public.gmane.org>
2011-10-16  5:38               ` Kent Overstreet
     [not found]                 ` <CAC7rs0vCA_j9O8-=Xouu0qH+yQxg8zYTP4K802TFJ2sm46OLfg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-10-17 13:52                   ` Brad Campbell
     [not found]                     ` <4E9C330C.6090801-+nnirC7rrGZibQn6LdNjmg@public.gmane.org>
2011-10-18  4:48                       ` Kent Overstreet [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=20111018044853.GA11435@moria \
    --to=kent.overstreet-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lists2009-+nnirC7rrGZibQn6LdNjmg@public.gmane.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.