Comment 3 for bug 1758697

2018年3月26日(月) 23:20 Ryan Harper <email address hidden>:

> I think the priority would be for any config that is required during the
> initial creation; other settings can be configured via scripts or other
> tuning mechanism. The cutoff, for example isn't something curtin should
> do by default ,rather it's a knob for benchmarking. I'd think the
> benchmark test would set and clear that as needed.
>

I agree that those flags can be changed on the fly and good on the
benchmarking story. But what if we want to set the value permanently in a
new deployment after coming up with a good value with benchmarking/testing?

With juju story, I'm not sure it's appropriate to configure those with
charms since they don't have enough idea about bcache because they didn't
create it. I thought curtin is the only sensible place, but I'm not 100%
sure.

> I think the following config options make sense (creation time
> settings):
>
> --data-offset <sectors> # defaults to 8k, but could get aligned for RAID
> backing devices
> --cset-uuid <UUID> # maas already sents UUID values for filesystems,
> it could set these too
>
> Most of the rest can be changed at runtime. We also need to investigate
> to see if the
> bcache sysfs changes are persistent across reboot.
>
> Besides the cutoff setting, are there other tunables that you would find
> useful to have inplace at install time?
>
> ** Changed in: curtin
> Importance: Undecided => Wishlist
>
> ** Changed in: curtin
> Status: New => Triaged
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1758697
>
> Title:
> support advanced bcache tuning flags
>
> Status in curtin:
> Triaged
>
> Bug description:
> It would be nice if curin supported some bcache tuning flags in
> addition to the current cache_mode settings.
>
> For example, a config flag for sequential_cutoff would be nice to have
> to maximize the usage of SSD.
>
> > - Bad performance, or traffic not going to the SSD that you'd expect
> >
> > By default, bcache doesn't cache everything. It tries to skip
> sequential IO -
> > because you really want to be caching the random IO, and if you
> copy a 10
> > gigabyte file you probably don't want that pushing 10 gigabytes of
> randomly
> > accessed data out of your cache.
> >
> > But if you want to benchmark reads from cache, and you start out
> with fio
> > writing an 8 gigabyte test file - so you want to disable that::
> >
> > # echo 0 > /sys/block/bcache0/bcache/sequential_cutoff
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/curtin/+bug/1758697/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=curtin; status=Triaged; importance=Wishlist;
> assignee=None;
> Launchpad-Bug-Tags: cpe-onsite
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: nobuto raharper
> Launchpad-Bug-Reporter: Nobuto Murata (nobuto)
> Launchpad-Bug-Modifier: Ryan Harper (raharper)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: nobuto
>