On Wed, Jun 4, 2014 at 12:58 AM, Sage Weil s...@inktank.com wrote:
On Thu, 22 May 2014, Ilya Dryomov wrote:
Add support for mon_get_version requests to libceph. This reuses much
of the ceph_mon_generic_request infrastructure, with one exception.
Older OSDs don't set mon_get_version reply
On Tue, Jun 3, 2014 at 6:19 PM, Ilya Storozhilov
ilya_storozhi...@epam.com wrote:
So it seems, that this is up to packager what to put to RPM_OPT_FLAGS
environment variable on packaging. Maybe someone knows what particular value
is used?
Thank you!
You can see what the actual value is by
Hello Ruben, Jeff, Daniel and others,
thank you very much for excellent assistance! :)
Best Regards,
Ilya Storozhilov
Lead Software Engineer
EPAM Systems
Tver office, Russia
GMT+4
EPAM Internal ext.: 55529
Office phone:+7 (4822) 630-070 ext. 55529
Office fax: +7 (4822)
Hello Ian,
Thanks for your interest.
On Mon, Jun 02, 2014 at 06:37:48PM -0400, Ian Colle wrote:
Thanks, Filippos! Very interesting reading.
Are you comfortable enough yet to remove the RAID-1 from your architecture and
get all that space back?
Actually, we are not ready to do that yet.
Hi,
When playing around with firefly, I noticed that the content-type I'm
setting when doing multi-part upload is not taken into account.
And looking at the rados object, I can see the xattr present on the
.meta file (upload obj), but when doing a complete, that object is
removed and the
On Monday 02 June 2014, Joseph S. Myers wrote:
On Mon, 2 Jun 2014, Arnd Bergmann wrote:
Ok. Sorry about missing linux-api, I confused it with linux-arch, which
may not be as relevant here, except for the one question whether we
actually want to have the new ABI on all 32-bit architectures
This is a known issue (8452). We have a fix for that and we'll get it
to firefly.
Thanks,
Yehuda
On Wed, Jun 4, 2014 at 8:10 AM, Sylvain Munaut
s.mun...@whatever-company.com wrote:
Hi,
When playing around with firefly, I noticed that the content-type I'm
setting when doing multi-part upload
This is a known issue (8452). We have a fix for that and we'll get it
to firefly.
Ok, great. Somehow my search didn't turn that up.
Looking at the patch, shouldn't the
meta_obj.set_in_extra_data(true);
be moved as well ?
Cheers,
Sylvain
--
To unsubscribe from this list: send the line
On Wed, Jun 4, 2014 at 9:07 AM, Sylvain Munaut
s.mun...@whatever-company.com wrote:
This is a known issue (8452). We have a fix for that and we'll get it
to firefly.
Ok, great. Somehow my search didn't turn that up.
Looking at the patch, shouldn't the
meta_obj.set_in_extra_data(true);
ida_destroy() needs to be called on module exit to release ida caches.
Signed-off-by: Ilya Dryomov ilya.dryo...@inktank.com
---
drivers/block/rbd.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index 94747afc2e78..ecdd4aee173c 100644
---
On 06/04/2014 11:38 AM, Ilya Dryomov wrote:
ida_destroy() needs to be called on module exit to release ida caches.
Looks good to me.
Reviewed-by: Alex Elder el...@linaro.org
Signed-off-by: Ilya Dryomov ilya.dryo...@inktank.com
---
drivers/block/rbd.c |1 +
1 file changed, 1
On Wed, 4 Jun 2014, Arnd Bergmann wrote:
On Tuesday 03 June 2014, Dave Chinner wrote:
Just ot be pedantic, inodes don't need 96 bit timestamps - some
filesystems can *support up to* 96 bit timestamps. If the kernel
only supports 64 bit timestamps and that's all the kernel can
represent,
On Wednesday 04 June 2014 13:30:32 Nicolas Pitre wrote:
On Wed, 4 Jun 2014, Arnd Bergmann wrote:
On Tuesday 03 June 2014, Dave Chinner wrote:
Just ot be pedantic, inodes don't need 96 bit timestamps - some
filesystems can *support up to* 96 bit timestamps. If the kernel
only supports
On 06/04/2014 12:24 PM, Arnd Bergmann wrote:
For other timekeeping stuff in the kernel, I agree that using some
64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds,
...) has advantages, that's exactly the point I was making earlier
against simply extending the internal
14 matches
Mail list logo
