At now for synchronous-fs, all write-operations use ceph_sync_mode.
But for the file which opened with O_SYNC, it don't use sync_mode.
The behaviour of them should be the same.
For fs which mounted using '-o sync', it want all I/O to the filesystem
should be done synchronously.But the ceph-sync-mod
Hi,
I have done some work on a version of the Wireshark plugin to
re-structure it so it may be possible to push upstream at some point. At
the moment it handles connection establishment, setting up some
conversational state tracking and decoding a few of the message types.
Supporting other me
On Wednesday 26 of June 2013 14:42:27 Josh Durgin wrote:
> On 06/26/2013 11:15 AM, Josh Durgin wrote:
> > On 06/26/2013 05:40 AM, Karol Jurak wrote:
> >> Hi,
> >>
> >> I'm using ceph 0.56.6 and kernel 3.9.7 and it looks like modifying RBD
> >> image
> >> also changes it's snapshot. I can reproduce
On Thu, 27 Jun 2013, Kevin Jones wrote:
> Hi,
>
> I have done some work on a version of the Wireshark plugin to re-structure it
> so it may be possible to push upstream at some point. At the moment it handles
> connection establishment, setting up some conversational state tracking and
> decoding
On 06/26/2013 03:06 PM, Josh Durgin wrote:
> Sending the right snapshot context with each write is required for
> snapshots to work. Due to the ordering of calls, the snapshot context
> is never set for any requests. This causes writes to the current
> version of the image to be reflected in all sn
Hi Ilya!
On Thu, 27 Jun 2013, Ilya Storozhilov wrote:
> Hi Matt (CC Sage, David, Adam),
>
>
> we have completed with our prototype of NFS/CIFS frontends to CEPH
> filesystem. In order to do it we had to fork ?wip-libcephfs? branch (see
> https://github.com/ferustigris/ceph and it?s ?open_by_hand
Hi Alex!
On Thu, 27 Jun 2013, Alex Elder wrote:
> On 06/26/2013 03:06 PM, Josh Durgin wrote:
> > Sending the right snapshot context with each write is required for
> > snapshots to work. Due to the ordering of calls, the snapshot context
> > is never set for any requests. This causes writes to the
Hi Sage,
Adam and I haven't looked in detail yet, but based on the prior email
discussion, and not counting nits, Ilya's changes seem fine.
If you agree, I and Adam take on the task of rebasing all our changes currently
on wip-libcephfs, into a small number of changes, following your lead in th
Hi Yehuda,
I went thru http://tracker.ceph.com/projects/rgw/issues today ( all 22
of them ;-) and contributed a patch to
http://tracker.ceph.com/issues/5324 ( that was an easy one ). I'd be
happy to either fix more bugs on the current development branch or
contribute to the geo-replication
https:/
Hi All,
Just to confirm what Adam and I are doing on this end, ie, this is our plan to
rebase wip-libcephfs following wip-libcephfs-rebase.
* proceeding commit-wise on wip-libcephfs-rebase, mapping each change back to a
commit in wip-libcephfs
** striking out anything marked reject in rebase
**
On Thu, 27 Jun 2013, Matt W. Benjamin wrote:
> Hi Sage,
>
> Adam and I haven't looked in detail yet, but based on the prior email
> discussion, and not counting nits, Ilya's changes seem fine.
>
> If you agree, I and Adam take on the task of rebasing all our changes
> currently on wip-libcephfs
Hi Sage,
- "Sage Weil" wrote:
>
> It might be simpler to just use the branch I already started and fix
> up
> the commit messages (git rebase -i master, 'e' for each commit, and
> git
> commit --amend on each to adjust the changelog).
Yes, doing exactly that.
>
> > Our work in progres
On Thu, 27 Jun 2013, Matt W. Benjamin wrote:
> Just to confirm what Adam and I are doing on this end, ie, this is our plan
> to rebase wip-libcephfs following wip-libcephfs-rebase.
>
> * proceeding commit-wise on wip-libcephfs-rebase, mapping each change back to
> a commit in wip-libcephfs
I wo
13 matches
Mail list logo
