On Mon, Apr 11, 2016 at 9:56 AM, Raghavendra Gowdappa
wrote:
>
> > +Raghavendra G who implemented this option in write-behind, to this
> > upstream patch review discussion
>
> Thanks Pranith. Kritika did inform us about the discussion. We were
> working on ways to find out solutions to the proble
Am 09.05.2016 um 08:38 hat Raghavendra Talur geschrieben:
>
>
> On Mon, Apr 11, 2016 at 9:56 AM, Raghavendra Gowdappa
> wrote:
>
>
> > +Raghavendra G who implemented this option in write-behind, to this
> > upstream patch review discussion
>
> Thanks Pranith. Kritika did inform us
> +Raghavendra G who implemented this option in write-behind, to this
> upstream patch review discussion
Thanks Pranith. Kritika did inform us about the discussion. We were working on
ways to find out solutions to the problems raised (and it was a long festive
weekend in Bangalore).
Sorry for
On Wed, Apr 06, 2016 at 01:02:16PM +0200, Kevin Wolf wrote:
> [ Adding some CCs ]
>
> Am 06.04.2016 um 05:29 hat Jeff Cody geschrieben:
> > Upon receiving an I/O error after an fsync, by default gluster will
> > dump its cache. However, QEMU will retry the fsync, which is especially
> > useful wh
+Raghavendra G who implemented this option in write-behind, to this
upstream patch review discussion
Pranith
On 04/06/2016 06:50 PM, Kevin Wolf wrote:
Am 06.04.2016 um 15:10 hat Jeff Cody geschrieben:
On Wed, Apr 06, 2016 at 01:51:59PM +0200, Kevin Wolf wrote:
Am 06.04.2016 um 13:41 hat Kevin
On Wed, Apr 06, 2016 at 04:47:32PM +0200, Niels de Vos wrote:
> On Wed, Apr 06, 2016 at 08:44:18AM -0400, Jeff Cody wrote:
> > On Wed, Apr 06, 2016 at 01:02:16PM +0200, Kevin Wolf wrote:
> > > [ Adding some CCs ]
> > >
> > > Am 06.04.2016 um 05:29 hat Jeff Cody geschrieben:
> > > > Upon receiving
On Wed, Apr 06, 2016 at 08:44:18AM -0400, Jeff Cody wrote:
> On Wed, Apr 06, 2016 at 01:02:16PM +0200, Kevin Wolf wrote:
> > [ Adding some CCs ]
> >
> > Am 06.04.2016 um 05:29 hat Jeff Cody geschrieben:
> > > Upon receiving an I/O error after an fsync, by default gluster will
> > > dump its cache.
We had a thread discussing this not on the upstream list.
My summary of the thread is that I don't understand why gluster should drop
cached data after a failed fsync() for any open file. For closed files, I think
it might still happen but this is the same as any file system (and unlikely to
Am 06.04.2016 um 15:10 hat Jeff Cody geschrieben:
> On Wed, Apr 06, 2016 at 01:51:59PM +0200, Kevin Wolf wrote:
> > Am 06.04.2016 um 13:41 hat Kevin Wolf geschrieben:
> > > Am 06.04.2016 um 13:19 hat Ric Wheeler geschrieben:
> > > >
> > > > We had a thread discussing this not on the upstream list.
On Wed, Apr 06, 2016 at 01:51:59PM +0200, Kevin Wolf wrote:
> Am 06.04.2016 um 13:41 hat Kevin Wolf geschrieben:
> > Am 06.04.2016 um 13:19 hat Ric Wheeler geschrieben:
> > >
> > > We had a thread discussing this not on the upstream list.
> > >
> > > My summary of the thread is that I don't under
On Wed, Apr 06, 2016 at 01:02:16PM +0200, Kevin Wolf wrote:
> [ Adding some CCs ]
>
> Am 06.04.2016 um 05:29 hat Jeff Cody geschrieben:
> > Upon receiving an I/O error after an fsync, by default gluster will
> > dump its cache. However, QEMU will retry the fsync, which is especially
> > useful wh
Am 06.04.2016 um 13:41 hat Kevin Wolf geschrieben:
> Am 06.04.2016 um 13:19 hat Ric Wheeler geschrieben:
> >
> > We had a thread discussing this not on the upstream list.
> >
> > My summary of the thread is that I don't understand why gluster
> > should drop cached data after a failed fsync() for
Am 06.04.2016 um 13:19 hat Ric Wheeler geschrieben:
>
> We had a thread discussing this not on the upstream list.
>
> My summary of the thread is that I don't understand why gluster
> should drop cached data after a failed fsync() for any open file.
It certainly shouldn't, but it does by default
[ Adding some CCs ]
Am 06.04.2016 um 05:29 hat Jeff Cody geschrieben:
> Upon receiving an I/O error after an fsync, by default gluster will
> dump its cache. However, QEMU will retry the fsync, which is especially
> useful when encountering errors such as ENOSPC when using the werror=stop
> optio
Upon receiving an I/O error after an fsync, by default gluster will
dump its cache. However, QEMU will retry the fsync, which is especially
useful when encountering errors such as ENOSPC when using the werror=stop
option. When using caching with gluster, however, the last written data
will be los
15 matches
Mail list logo
