From: Somnath Roy <Somnath.Roy@sandisk.com>
To: Sage Weil <sage@newdream.net>, Igor Fedotov <ifedotov@mirantis.com>
Cc: ceph-devel <ceph-devel@vger.kernel.org>
Subject: RE: uint32_t BlueStore::Extent::logical_offset?
Date: Tue, 22 Nov 2016 21:53:18 +0000 [thread overview]
Message-ID: <BY2PR02MB39660B0A6749CC3D6AF505EF4B40@BY2PR02MB396.namprd02.prod.outlook.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1611222146240.11236@piezo.us.to>
Sage,
OSD max obect size in the latest master is 100G , it used to be smaller..
OPTION(osd_max_object_size, OPT_U64, 100*1024L*1024L*1024L) // OSD's maximum object size
Thanks & Regards
Somnath
-----Original Message-----
From: ceph-devel-owner@vger.kernel.org [mailto:ceph-devel-owner@vger.kernel.org] On Behalf Of Sage Weil
Sent: Tuesday, November 22, 2016 1:47 PM
To: Igor Fedotov
Cc: ceph-devel
Subject: Re: uint32_t BlueStore::Extent::logical_offset?
On Tue, 22 Nov 2016, Igor Fedotov wrote:
> Hi Sage,
>
>
> I'm wondering why BlueStore::Extent::logical_offset is 32-bit wide.
>
> IMHO it's to be uint64_t unless we limit onode size to 4Gb.
>
> Looks like we have implicit truncate when doing set_lextent/new Extent
> at the moment and hence some issues with large onodes are possible.
The max object size enforced in the OSD is ~128 MB (or in that neighborhood, if I remember correctly). We really shouldn't be storing individual rados objects that are orders of magnitude larger than that.
sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).
next prev parent reply other threads:[~2016-11-22 22:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-22 16:58 uint32_t BlueStore::Extent::logical_offset? Igor Fedotov
2016-11-22 17:06 ` Gregory Farnum
2016-11-22 17:15 ` Igor Fedotov
2016-11-22 21:47 ` Sage Weil
2016-11-22 21:53 ` Somnath Roy [this message]
2016-11-22 22:42 ` Matt Benjamin
2016-11-22 22:45 ` Sage Weil
2016-11-22 23:02 ` Matt Benjamin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BY2PR02MB39660B0A6749CC3D6AF505EF4B40@BY2PR02MB396.namprd02.prod.outlook.com \
--to=somnath.roy@sandisk.com \
--cc=ceph-devel@vger.kernel.org \
--cc=ifedotov@mirantis.com \
--cc=sage@newdream.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.