From: Alex Lyakas <alex.btrfs@zadarastorage.com>
To: "Swâmi Petaramesh" <swami@petaramesh.org>
Cc: "BTRFS, Linux" <linux-btrfs@vger.kernel.org>
Subject: Re: inode_cache
Date: Wed, 24 Oct 2012 11:58:45 +0200 [thread overview]
Message-ID: <CAOcd+r1Gt5XoPuRB3vyDak21xNFufCLvfATbFvCyt3foq4RfJw@mail.gmail.com> (raw)
In-Reply-To: <507AA0E7.30706@petaramesh.org>
Swami,
I believe the only thing that "inode_cache" mount option does is
allowing to reuse inode numbers. Like if you had a file with inode
number=X and you delete this file, then you will never have inode=X in
the same file tree (subvolume) again. You can look at
btrfs_find_free_ino() that allocates an inode number to understand
this better. Since inode number is u64, it is perhaps unlikely that
you ever run out of inode numbers. But still this mount option is
present and implemented, so perhaps there is some reason for that.
You can also look at "Free space cache writeback issue" note from Jan
on the list; looks like he discovered some issue with that option.
Alex.
On Sun, Oct 14, 2012 at 1:24 PM, Swâmi Petaramesh <swami@petaramesh.org> wrote:
> Hi there,
>
> On a performance standpoint - and on Ubuntu Quantall kernel 3.5.0-17 -
> is it advisable to mount BTRFS with "inode_cache" ?
>
> Is there any risk or counterpart doing so ?
>
> TIA, kind regards.
>
> --
> Swāmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E
> Ne cherchez pas : Je ne suis pas sur Facebook.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2012-10-24 9:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-14 11:24 inode_cache Swâmi Petaramesh
2012-10-24 9:58 ` Alex Lyakas [this message]
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=CAOcd+r1Gt5XoPuRB3vyDak21xNFufCLvfATbFvCyt3foq4RfJw@mail.gmail.com \
--to=alex.btrfs@zadarastorage.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=swami@petaramesh.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).