On Fri, Feb 01 2013 at 10:39am -0500,
Kent Overstreet <koverstreet@xxxxxxxxxx> wrote:
> On Thu, Jan 31, 2013 at 10:38:11PM -0500, Mike Snitzer wrote:
> > I'm just seeing extra newlines (empty lines), e.g.:
> > bcache: run_cache_set() invalidating existing data
>
> Oh I see it, I screwed that up when I converted a bunch of stuff to
> pr_*() macros and my brain was so used to reading the same stuff I
> didn't notice it. I'll have that fixed in a minute.
>
> > > > - bcache doesn't appear to be establishing proper holders on the devices
> > > > it uses for the backing and cache devices.
> > > > - lsblk doesn't show any associations with bcache devices.
> > >
> > > How's that created - what function am I looking for?
> >
> > bd_link_disk_holder and bd_unlink_disk_holder
>
> Ok, that's done - it's in the testing branch
>
> >
> > > > - the fio utility isn't able to get any stats for the bcache device or
> > > > the devices bcache uses.
> > >
> > > I'd been meaning to fix that, never got around to figuring out how those
> > > stats are generated. Function/file you can point me to?
> >
> > I think you'll get the stats for via genhd (add_disk) -- the stats are
> > the 'disk_stats dkstats' member of the genhd's hd_struct. But as of
> > now you'll notice that /sys/block/bcacheX/stat only ever contains 0s.
>
> >
> > part_stat_inc, part_stat_add are the low-level methods for driving the
> > counters up. But I'm not sure why bcache isn't getting these stats --
> > disk stats are something we get for free with DM devices so I haven't
> > really had to dig into these mechanics in detail.
>
> Ah, I remember coming across that before now. Got that fixed too, it's
> in both the stable and testing branches.
>
> And dm and md are both calling it from their make_request functions,
> which is why bcache wasn't getting it.
stats and lsblk look good.
> > > > - if I 'stop' a bcache device (using sysfs) while it is mounted; once I
> > > > unmount the filesystem the device that bcache was using as a cache
> > > > still has an open count of 1 but the bcache device then no longer
> > > > exists
> > >
> > > You mean the backing device isn't open, just the cache device?
> > >
> > > That's intended behaviour, backing and cache devices have separate
> > > lifetimes (and you can attach many backing devices to a single cache).
> > >
> > > You just have to stop the cache set separately, via
> > > /sys/fs/bcache/<uuid>/stop or /sys/block/<cache device>/bcache/set/stop
> >
> > The /dev/bcacheX device was mounted. I issued 1 to
> > /sys/block/#{bcache_name}/bcache/stop before unmounting. I then
> > unmounted /dev/bcacheX, the remaining bcache device infrastructure was
> > torn down. But after that the device that was the cache device was
> > still held open -- seems like a reference leaked.
>
> Was there still a directory in /sys/fs/bcache?
Yes, after unmount the /dev/bcacheX device is deleted but the
associated /sys/fs/bcache/<uuid> still exists.
Echoing 1 to /sys/fs/bcache/<uuid>/stop cleared it up.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
