All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Durgin <josh.durgin@inktank.com>
To: Tommi Virtanen <tv@inktank.com>
Cc: Travis Rhoden <trhoden@gmail.com>, ceph-devel@vger.kernel.org
Subject: Re: safe to defrag XFS on live system?
Date: Fri, 14 Sep 2012 10:15:00 -0700	[thread overview]
Message-ID: <50536614.8030707@inktank.com> (raw)
In-Reply-To: <CADvuQREvqUG0Xe7gf_LMtXsvZMxX88TT7imi8Cfj2ihA0s+VeQ@mail.gmail.com>

On 09/14/2012 10:06 AM, Tommi Virtanen wrote:
> On Fri, Sep 14, 2012 at 8:51 AM, Travis Rhoden <trhoden@gmail.com> wrote:
>> On a running Ceph cluster using XFS for the OSD's, is it safe to
>> defrag the OSD devices while the system is live?
>>
>> I did a quick check of one device:
>>
>> xfs_db -c frag -r /dev/sdd
>> actual 637596, ideal 144935, fragmentation factor 77.27%
>
> If it's safe to defrag xfs while it's mounted in general, it's safe to
> do it when an OSD is running. Xfs either keeps its promises as a
> filesystem, or doesn't.
>
> How that affects performance is another question..
>
>> While I'm talking about XFS...  I know that RBD's use a default object
>> size of 4MB.  I've stuck with that so far..  Would it be beneficial to
>> mount XFS with -o allocsize=4M ?  What is the object size that gets
>> used for non-RBD cases -- i.e. just dumping objects into data pool?
>
> Don't know about -o allocsize -- benchmark it!
>
> Objects are the size they are; Ceph does not dictate any size. RBD and
> CephFS both stripe a thing (image/file) over multiple objects, at a
> constant size; you already know that, RBD defaults to 4MB. Other users
> of RADOS create objects of any size they please, and an OSD stores
> those as files in the underlying filesystem.

Also keep in mind that objects can be sparse - the 4MB stripe size
doesn't mean the full 4MB are used by an object in CephFS or RBD.


  reply	other threads:[~2012-09-14 17:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-14 15:51 safe to defrag XFS on live system? Travis Rhoden
2012-09-14 17:06 ` Tommi Virtanen
2012-09-14 17:15   ` Josh Durgin [this message]
2012-09-14 17:15   ` Nick Couchman
2012-09-14 17:22     ` Travis Rhoden
2012-09-14 18:49     ` Mark Nelson
2012-09-14 18:56       ` Nick Couchman
2012-09-14 19:50         ` Mark Nelson
2012-09-14 20:01           ` Nick Couchman
2012-09-14 18:56       ` Travis Rhoden

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=50536614.8030707@inktank.com \
    --to=josh.durgin@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=trhoden@gmail.com \
    --cc=tv@inktank.com \
    /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.