I've wondered about this for a long time. Given that consumption monitoring
already exists in the dmeventd thin plugin and can even trigger actions
like thin pools claiming available physical extents from the VG, it
certainly seems like there is an existing code structure there that we
could tie in
which could be problematic for something like bitrot
detection and could result in a lot of log noise, I'm guessing. And
administratively someone could still get in and remount the bricks as r/w,
so if you _really_ _really_ need it locked down you may also need selinux.
Dustin Black, RHCA
Senior
On Feb 15, 2017 5:39 PM, "Jeff Darcy" wrote:
One of the issues that has come up with multiplexing is that all of the
bricks in a process end up sharing a single log file. The reaction from
both of the people who have mentioned this is that we should find a way to
give each brick its own log even
print('saw ENOTEMPTY on stonewall, moving shared
directory')
> ext = str(binascii.b2a_hex(os.urandom(15)))
> shutil.move(master_invoke.network_dir,
master_invoke.network_dir + ext)
Dustin Black, RHCA
Senior Architect, So
l files. A
> presentation at the Berlin gluster summit evaluated this. The expectation
> is md-cache will go a long way towards helping that, before too long.
>
> Dan
>
>
>
> - Original Message -
> > From: "Dustin Black"
> > To: gluste
e hot tier that is to blame, but it is not always the same
replica pair.)
Can someone try recreating this scenario to see if the problem is
consistent? Please reach out if you need me to provide any further details.
Dustin Black, RHCA
Senior Architect, Software-Defined Storage
Red Hat, Inc.
(o) +
r/client/mount /path/to/binary/iozone
Dustin Black, RHCA
Senior Architect, Software-Defined Storage
Red Hat, Inc.
On Mon, Oct 10, 2016 at 3:48 PM, Menaka Mohan wrote:
> Hi,
>
>
> I am Menaka M. I am new to this open source world. Kindly help me with the
> following query.
>
>
I've been toying with maintaining presentations in asciidoc format, which
lends itself better to revision control and allows me to auto-publish to
multiple formats relatively easily.
Dustin L. Black, RHCA
Principal Cloud Success Architect
Red Hat, Inc. - Strategic Customer Engagement
(o) +1.212.5
