Add the official kernel repo as a remote to the same git repo
(with git remote add), fetch that repo, create a new branch to work
in, based on the btrfs-next branch, then merge in the other branch (or
vice-versa).
Note that btrfs-next is usually based on the latest released kernel
On Fri, Aug 02, 2013 at 05:12:49PM -0400, Mike Audia wrote:
v2:
* Stefan pointed out a missing break and that /proc/mounts does not show
the option.
* fixed missing goto and extra printk parameter after failed match_int
Forgive my naive question: I am using gmx's webclient which
Another newbie question is which version of the kernel do I need to
have in order to cleanly apply this patch? I am finding that it fails
to apply to the current stable kernel code (as of now it is v3.10.4)
which makes me think your patch has to be applied to a newer one? Are
you
On Sat, Aug 03, 2013 at 07:39:01AM -0400, Mike Audia wrote:
Another newbie question is which version of the kernel do I need to
have in order to cleanly apply this patch? I am finding that it fails
to apply to the current stable kernel code (as of now it is v3.10.4)
which makes me
v2:
* Stefan pointed out a missing break and that /proc/mounts does not show
the option.
* fixed missing goto and extra printk parameter after failed match_int
Forgive my naive question: I am using gmx's webclient which doesn't seem to
identify your patch as an attachment. I can simply
- Original Message -
From: Mike Audia
Sent: 08/02/13 05:12 PM
To: David Sterba, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2] btrfs: add mount option to set commit interval
v2:
* Stefan pointed out a missing break and that /proc/mounts does not show
the option.
* fixed
Another newbie question is which version of the kernel do I need to
have in order to cleanly apply this patch? I am finding that it fails
to apply to the current stable kernel code (as of now it is v3.10.4)
which makes me think your patch has to be applied to a newer one? Are
you patching
I'ts hardcoded to 30 seconds which is fine for most users. Higher values
defer data being synced to permanent storage with obvious consequences
when the system crashes. The upper bound is not forced, but a warning is
printed if it's more than 300 seconds (5 minutes).
Signed-off-by: David Sterba
