Wido den Hollander wrote:
> Is it a sane thing to look at 'features' which pools could have? Other
> features which might be set on a pool:
>
> - Read Only (all write operations return -EPERM)
> - Delete Protected
There's another pool feature I'd find very useful: a WORM flag, that permits
onl
Sage Weil wrote:
> On Fri, 16 Jan 2015, Alex Elsayed wrote:
>> Wido den Hollander wrote:
>>
>>
>> > Is it a sane thing to look at 'features' which pools could have? Other
>> > features which might be set on a pool:
>> >
>>
Sage Weil wrote:
> Hey Mark,
>
> I just watched Brendan Gregg's talk at SCALE (which was extremely good)
> and one of the things he mentioned is the importance of
> -fno-omit-frame-pointer. I notice we are setting it via do_autogen.sh
> (i.e., for developers) but not in the production builds. S
Commentary inline.
Note that when I talk about dependencies, I'm speaking as someone who does
distro packaging - and thus what would require manual changes on the
packager's part vs. ability to specify general constraints.
Sage Weil wrote:
> Hammer will most likely be v0.94[.x]. We're getting
Yehuda Sadeh-Weinraub wrote:
>
>
> - Original Message -
>> From: "Loic Dachary"
>> To: "Sage Weil" , ceph-devel@vger.kernel.org
>> Sent: Thursday, February 26, 2015 3:38:31 PM
>> Subject: Re: ceph versions
>>
>> Hi Sage,
>>
>> I prefer Option D because it's self explanatory. We could
Loic Dachary wrote:
>
>
> On 27/02/2015 13:59, Ilya Dryomov wrote:
>> On Fri, Feb 27, 2015 at 3:58 AM, Loic Dachary wrote:
>>>
>>>
>>> On 27/02/2015 00:59, Yehuda Sadeh-Weinraub wrote:
- Original Message -
> From: "Loic Dachary"
> To: "Sage Weil" , ceph-devel@vge
Loic Dachary wrote:
>
>
> On 27/02/2015 23:47, Alex Elsayed wrote:
>> Loic Dachary wrote:
>>
>>>
>>>
>>> On 27/02/2015 13:59, Ilya Dryomov wrote:
>>>> On Fri, Feb 27, 2015 at 3:58 AM, Loic Dachary wrote:
>&g
Owen Synge wrote:
> If I underwstand right you favor the user interface as:
>
> --with-init=systemd
> --with-init=sysv
> --with-init=upstart
> --with-init=bsd
Please do be sure to make --with-init=systemd respect the
--with-systemdsystemunitdir=PATH option, as some distros rely on that to
pro
Travis Rhoden wrote:
> On Tue, Jul 28, 2015 at 12:13 PM, Sage Weil wrote:
>> Hey,
>>
>> I've finally had some time to play with the systemd integration branch on
>> fedora 22. It's in wip-systemd and my current list of issues includes:
>>
>> - after mon creation ceph-create-keys isn't run automa
Sage Weil wrote:
> On Wed, 29 Jul 2015, Alex Elsayed wrote:
>> Travis Rhoden wrote:
>>
>> > On Tue, Jul 28, 2015 at 12:13 PM, Sage Weil wrote:
>> >> Hey,
>> >>
>> >> I've finally had some time to play with the systemd integra
Sage Weil wrote:
> On Wed, 29 Jul 2015, Alex Elsayed wrote:
>> Sage Weil wrote:
>>
>> > On Wed, 29 Jul 2015, Alex Elsayed wrote:
>>
>> Does it?
>>
>> If the mount point is (say) /var/ceph/$UUID, and ceph-osd can take a --
>> datadir para
Sage Weil wrote:
> On Wed, 29 Jul 2015, Alex Elsayed wrote:
>> My thinking is more that the "osd data = " key makes a lot less sense in
>> the systemd world overall - passing the OSD the full path on the
>> commandline via some --datadir would mean you could triv
Sage Weil wrote:
> On Tue, 4 Aug 2015, Wido den Hollander wrote:
>> On 03-08-15 22:25, Samuel Just wrote:
>> > It seems like it's about time for us to make the jump to C++11. This
>> > is probably going to have an impact on users of the librados C++
>> > bindings. It seems like such users would
Loic Dachary wrote:
> Hi Ceph,
>
> Reed-Solomon coding family is the only one that can keep the chuncks
> unencoded and therefore concatenable.
In my understanding, this is not strictly true - any 'systematic' code will
have the unencoded chunks remain available in this manner, and any non-
s
Alex Elsayed wrote:
> Loic Dachary wrote:
>
>> Hi Ceph,
>>
>
>> Reed-Solomon coding family is the only one that can keep the chuncks
>> unencoded and therefore concatenable.
>
>
> In my understanding, this is not strictly true - any 'systemati
Loic Dachary wrote:
>
>
> On 06/19/2013 03:14 AM, Alex Elsayed wrote:
>> Alex Elsayed wrote:
>>
>>> Loic Dachary wrote:
>>>
>>>> Hi Ceph,
>>>>
>>>
>>>> Reed-Solomon coding family is the only one tha
Loic Dachary wrote:
> Hi Alex,
>
> If I understand correctly, part of what you propose is to make use of
> fountain codes to optimize replicas transmissions. It could even be used
> to speed up replication by allowing existing copies to contribute to the
> completion of the others. Although this
I posted this as a comment on the blueprint, but I figured I'd say it here:
The thing I'd worry about here is that LevelDB's performance (along with
that of various other K/V stores) falls off a cliff for large values.
Symas (who make LMDB, used by OpenLDAP) did some benchmarking that shows
dra
Li Wang wrote:
> Hi,
>We want to implement encryption support for Ceph.
>Currently, we have the draft design,
>
> 1 When user mount a ceph directory for the first time, he can specify a
> passphrase and the encryption algorithm and length of key etc. These
> will be stored as extend attri
Dan van der Ster wrote:
> Hi Greg,
> AFAICT, this would allow single users to mount a subtree on CephFS and
> prevent them from writing where they are not permitted. But our
> use-case is different: we want to mount /cephfs/ from shared
> workstations and batch nodes to store personal home direct
Li Wang wrote:
> Hi Alex,
>Thanks for your comments.
>
>
> On 11/13/2013 09:07 AM, Alex Elsayed wrote:
>> Li Wang wrote:
>>
>>> Hi,
>>> We want to implement encryption support for Ceph.
>>> Currently, we have the draft design,
&g
Jean-Tiare LE BIGOT wrote:
> Hi,
>
> I started to implement 'DISCARD' support in RBD kernel driver as
> described on http://tracker.ceph.com/issues/190
>
> This first (easy) step was to add at the end of
> drivers/block/rbd.c:rbd_init_disk
>
> /* Advertise discard support for aligned block
Sage Weil wrote:
> Now that the world seems to be converging on systemd, we need to sort out
> a proper strategy for Ceph. Right now we have both sysvinit (old and
> crufty but functional) and upstart, but neither are especially nice to
> work with.
>
> The first order of business is to identif
mark.doff...@codethink.co.uk wrote:
> From: Mark Doffman
>
> Hi All,
>
> The following is a third version of a patch series that adds the ability
> to use a ceph distributed file system as the root device.
Would you mind expanding on why you want to do this in the kernel, instead
of using an
Gregory Farnum wrote:
> On Mon, Jul 21, 2014 at 3:27 PM, Daniel Hofmann wrote:
>> Preamble: you might want to read the decent formatted version of this
>> mail at:
>>> https://gist.github.com/daniel-j-h/2daae2237bb21596c97d
>> ---
>>
>> Ceph's object mapping depends on the rjenkins hash func
Gah, typed "fletcher4" when I meant "rjenkins" - still, the same applies.
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Sage Weil wrote:
> [Adding ceph-devel]
>
> On Mon, 21 Jul 2014, Wang, Zhiqiang wrote:
>> Sage,
>>
>> I agree with you that promotion on the 2nd read could improve cache
>> tiering's performance for some kinds of workloads. The general idea here
>> is to implement some kinds of policies in the ca
Sage Weil wrote:
> On Fri, 25 Jul 2014, Daniel Hofmann wrote:
>> The main issue however is not the hash's strength, but the fact that
>> once pre-computed, I'm able to use preimages on **every Ceph cluster out
>> there**. (As the hash functions's output is a deterministic function of
>> the object
Loic Dachary wrote:
> Hi Joao,
> It is quite impossible for us (non lawyers) to draw the line that
> separates paranoïa and common sense. Reason why most discussions on these
> topics turn short. I cannot dismiss the scenario you describe and I'm
> quite sure asking a lawyer would not clarify an
Loic Dachary wrote:
> Hi Alex,
>
> On 17/08/2015 22:19, Alex Elsayed wrote:
>> This is where I see a subtle, but meaningful distinction: Accepting from
>> aliases *which have submitted a DCO* means that the person behind the
>> alias, even if we don't know their
Loic Dachary wrote:
>
>
> On 17/08/2015 22:58, Alex Elsayed wrote:
>
>> The S-o-B tag, then, simply says "If you look, you'll find my affirmation
>> of intent to follow the DCO" - it is not, in itself, anything other than
>> a pointer. This prevent
Sage Weil wrote:
> On Mon, 17 Aug 2015, Alex Elsayed wrote:
>> Loic Dachary wrote:
>>
>> > Hi Alex,
>> >
>> > On 17/08/2015 22:19, Alex Elsayed wrote:
>>
>> >> This is where I see a subtle, but meaningful distinction: Accepting
&g
Sage Weil wrote:
> The main things that come to mind:
>
> - zfs checksumming
> - ceph can eventually use zfs snapshots similarly to how it uses btrfs
> snapshots to create stable checkpoints as journal reference points,
> allowing parallel (instead of writeahead) journaling
> - can use raidz
dennis chen wrote:
> Hi All,
>
> Recently I want to use IBM AIX as the ceph client to take use of the
> cephFS and rbd service from ceph,
> but after some investigation, seem there's no support for AIX as the
> ceph client. Is there some clues about this? or is there some workaround
> that I can
Dan Mick inktank.com> writes:
>
> On 06/18/2012 11:01 AM, Sage Weil wrote:
> > On Mon, 18 Jun 2012, Josh Durgin wrote:
> $ rbd copyup pool2/child1
> "disown" and "adopt"? :) (actually I started as a joke, but really I
> kinda like that; fits with the parent-child name)
The issue I
Martin Fick wrote:
> Hello,
>
> I have a questions with respect to RADOS and RBD and the cluster monitor
> daemons.
I'm not one of the developers, but I've been following for a while and one
of your sub-questions intriqued me; specifically:
>...This would open up the use of RBD devices for lin
Replying to a response that was off-list:
On Wed, May 5, 2010 at 9:02 AM, Martin Fick wrote:
>
> --- On Wed, 5/5/10, Alex Elsayed wrote:
>
> > >...This would open up the use of RBD devices for linux
> > > containers or linux vservers which could run on any
> > &
37 matches
Mail list logo
