From: Sean Bartell <wingedtachikoma@gmail.com>
To: Yuehai Xu <yuehaixu@gmail.com>
Cc: linux-btrfs@vger.kernel.org, yhxu@wayne.edu, chris.mason@oracle.com
Subject: Re: BTRFS && SSD
Date: Wed, 29 Sep 2010 13:08:55 -0400 [thread overview]
Message-ID: <20100929170855.GA4635@lelouch.nomadic.ncsu.edu> (raw)
In-Reply-To: <AANLkTik9qiqtePxAhaJTyM7Q-g1nTgw9krTZFf_DaYxn@mail.gmail.com>
On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote:
> I know BTRFS is a kind of Log-structured File System, which doesn't do
> overwrite. Here is my question, suppose file A is overwritten by A',
> instead of writing A' to the original place of A, a new place is
> selected to store it. However, we know that the address of a file
> should be recorded in its inode. In such case, the corresponding part
> in inode of A should update from the original place A to the new place
> A', is this a kind of overwrite actually? I think no matter what
> design it is for Log-Structured FS, a mapping table is always needed,
> such as inode map, DAT, etc. When a update operation happens for this
> mapping table, is it actually a kind of over-write? If it is, is it a
> bottleneck for the performance of write for SSD?
In btrfs, this is solved by doing the same thing for the inode--a new
place for the leaf holding the inode is chosen. Then the parent of the
leaf must point to the new position of the leaf, so the parent is moved,
and the parent's parent, etc. This goes all the way up to the
superblocks, which are actually overwritten one at a time.
> What do you think the major work that BTRFS can do to improve the
> performance for SSD? I know FTL has becomes smarter and smarter, the
> idea of log-structured file system is always implemented inside the
> SSD by FTL, in that case, it sounds all the issues have been solved no
> matter what the FS it is in upper stack. But at least, from the
> results of benchmarks on the internet show that the performance from
> different FS are quite different, such as NILFS2 and BTRFS.
next prev parent reply other threads:[~2010-09-29 17:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-29 15:30 BTRFS && SSD Yuehai Xu
2010-09-29 17:08 ` Sean Bartell [this message]
2010-09-29 18:45 ` Yuehai Xu
2010-09-29 19:59 ` Sean Bartell
2010-09-29 21:31 ` Yuehai Xu
2010-09-30 7:15 ` Sander
2010-09-30 12:06 ` Yuehai Xu
2010-09-30 13:45 ` Sander
2010-09-30 7:51 ` David Brown
2010-09-30 12:04 ` Yuehai Xu
2010-09-29 19:39 ` Aryeh Gregor
2010-09-29 20:08 ` Sean Bartell
[not found] ` <20100929173757.7cf18c0d@simplux>
2010-09-29 18:38 ` Yuehai Xu
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=20100929170855.GA4635@lelouch.nomadic.ncsu.edu \
--to=wingedtachikoma@gmail.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=yhxu@wayne.edu \
--cc=yuehaixu@gmail.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 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).