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 whi
> 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 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 m
> > 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
> >
> 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 patchi
> - 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
> 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
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
-
