Hi!
> >> Which is also the approach that I've been advocating for here, instead
> >> of a kernel patch...
> >
> > I know you've been advocating the use of udev for IO scheduler selection.
> > But do you want to force everybody to use udev? And for people who build
> > their own (usually small)
Hi!
> I talked to Pavel a bit back and it turns out he has a
> usecase for BFQ as well and I bet he also would like it
> as default scheduler for that system (Pavel tell us more,
> I don't remember what it was!)
I'm not sure I remember clearly, either.
IIRC I was working with ionice on spinning
Hi!
> Proposed solution:
>
> Instead of fixing such semantics and trying to get all filesystems to do it
> right, we can easily do away with all freezing calls if the filesystem
> implements a proper freeze_fs() callback. The following 9 filesystems have
> freeze_fs() implemented as such we can
Hi!
> On 9/14/17 00:37, Philipp Guendisch wrote:
> > This patch adds a software based secure erase option to improve data
> > confidentiality. The CONFIG_BLK_DEV_SECURE_ERASE option enables a mount
> > flag called 'sw_secure_erase'. When you mount a volume with this flag,
> > every discard call
On Tue 2017-10-03 22:38:33, Jiri Kosina wrote:
> On Tue, 3 Oct 2017, Pavel Machek wrote:
>
> > > This point I don't understand. What exactly do you mean?
> >
> > Hibernation:
> >
> > We freeze, do system snapshot, unfreeze, and write image to
> >
Hi!
> > Can memory management doing background writes be a problem?
>
> This point I don't understand. What exactly do you mean?
Hibernation:
We freeze, do system snapshot, unfreeze, and write image to
disk. Memory management wakes up (this used to be called bdflush),
decides its time to write
On Tue 2017-10-03 11:53:13, Luis R. Rodriguez wrote:
> Now that all filesystems which used to rely on kthread
> freezing have been converted to filesystem freeze/thawing
> we can remove the kernel kthread freezer.
Are you surely-sure? You mentioned other in kernel sources of writes;
what about
On Thu 2016-09-15 10:43:54, Josef Bacik wrote:
> NBD can become contended on its single connection. We have to serialize all
> writes and we can only process one read response at a time. Fix this by
> allowing userspace to provide multiple connections to a single nbd device.
> This
> coupled
