On Sat, 10 May 2014, Kay Sievers wrote:
> On Sat, May 10, 2014 at 12:00 AM, Sage Weil wrote:
> > On Fri, 9 May 2014, Kay Sievers wrote:
> >> On Fri, May 9, 2014 at 11:31 PM, Sage Weil wrote:
> >> > The Ceph OSD initialization relies on identifying GPT partitions by type
> >> > in order to mount d
On Sat, May 10, 2014 at 12:00 AM, Sage Weil wrote:
> On Fri, 9 May 2014, Kay Sievers wrote:
>> On Fri, May 9, 2014 at 11:31 PM, Sage Weil wrote:
>> > The Ceph OSD initialization relies on identifying GPT partitions by type
>> > in order to mount data volumes and start daemons. Currently we ship
Hi Kay,
On Fri, 9 May 2014, Kay Sievers wrote:
> On Fri, May 9, 2014 at 11:31 PM, Sage Weil wrote:
> > The Ceph OSD initialization relies on identifying GPT partitions by type
> > in order to mount data volumes and start daemons. Currently we ship this
> > rule separately, but it is awkward to d
On Fri, May 9, 2014 at 11:31 PM, Sage Weil wrote:
> The Ceph OSD initialization relies on identifying GPT partitions by type
> in order to mount data volumes and start daemons. Currently we ship this
> rule separately, but it is awkward to duplicate the conditional logic that
> precedes this bloc
The Ceph OSD initialization relies on identifying GPT partitions by type
in order to mount data volumes and start daemons. Currently we ship this
rule separately, but it is awkward to duplicate the conditional logic that
precedes this block and it would be much simpler if it were simply included
i
On Mon, May 5, 2014 at 6:48 AM, dedede gfgfgf trtrtrtrtrtr
wrote:
Investigations showed that since in pam module we started to dup fifo
descriptor problem appeared. Dup does not set O_CLOEXEC flag. So
after fork/exec
all children processes have that descriptor and when parent which
open pam
