From: Gordan Bobic <gordan-UpbECiGlrmGsTnJN9+BGXg@public.gmane.org>
To: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: SSD and non-SSD Suitability
Date: Wed, 26 May 2010 11:18:02 +0100 [thread overview]
Message-ID: <4BFCF55A.80205@bobich.net> (raw)
I've got a somewhat broad question on the suitability of nilfs for
various workloads and different backing storage devices. From what I
understand from the documentation available, the idea is to always write
sequentially, and thus avoid slow random writes on old/naive SSDs. Hence
I have a few questions.
1) Modern SSDs (e.g. Intel) do this logical/physical mapping internally,
so that the writes happen sequentially anyway. Does nilfs demonstrably
provide additional benefits on such modern SSDs with sensible firmware?
2) Mechanical disks suffer from slow random writes (or any random
operation for that matter), too. Do the benefits of nilfs show in random
write performance on mechanical disks?
3) How does this affect real-world read performance if nilfs is used on
a mechanical disk? How much additional file fragmentation in absolute
terms does nilfs cause?
4) As the data gets expired, and snapshots get deleted, this will
inevitably lead to fragmentation, which will de-linearize writes as they
have to go into whatever holes are available in the data. How does this
affect nilfs write performance?
5) How does the specific writing amount measure against other file
systems (I'm specifically interested in comparisons vs. ext2). What I
mean by specific writing amount is for writing, say, 100,000 random
sized files, how many write operations and MBs (or sectors) of writes
are required for the exact same operation being performed on nilfs and
ext2 (e.g. as measured by vmstat -d).
Many thanks.
Gordan
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2010-05-26 10:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-26 10:18 Gordan Bobic [this message]
[not found] ` <4BFCF55A.80205-UpbECiGlrmGsTnJN9+BGXg@public.gmane.org>
2010-05-28 6:29 ` SSD and non-SSD Suitability Jiro SEKIBA
[not found] ` <87typspmiq.wl%jir-27yqGEOhnJbQT0dZR+AlfA@public.gmane.org>
2010-05-28 9:50 ` Gordan Bobic
[not found] ` <4BFF91E7.9000102-UpbECiGlrmGsTnJN9+BGXg@public.gmane.org>
2010-05-29 7:31 ` Jiro SEKIBA
[not found] ` <87d3wf17vj.wl%jir-27yqGEOhnJbQT0dZR+AlfA@public.gmane.org>
2010-05-29 7:50 ` David Arendt
[not found] ` <4C00C745.6050903-/LHdS3kC8BfYtjvyW6yDsg@public.gmane.org>
2010-05-29 8:45 ` Gordan Bobic
[not found] ` <4C00D433.2010406-UpbECiGlrmGsTnJN9+BGXg@public.gmane.org>
2010-05-29 8:56 ` David Arendt
2010-05-29 8:43 ` Gordan Bobic
[not found] ` <4C00D3B7.8060904-UpbECiGlrmGsTnJN9+BGXg@public.gmane.org>
2010-06-01 13:05 ` Jiro SEKIBA
2010-05-28 8:17 ` Vincent Diepeveen
[not found] ` <927E6E4B-B072-42EE-915A-FD34A88D478A-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
2010-05-28 9:24 ` Gordan Bobic
[not found] ` <4BFF8BD6.7080802-UpbECiGlrmGsTnJN9+BGXg@public.gmane.org>
2010-05-28 10:15 ` Vincent Diepeveen
[not found] ` <72C0FCE6-CE1A-4262-B89F-A1C3CBA99EAD-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
2010-05-28 10:44 ` Gordan Bobic
[not found] ` <4BFF9E74.6040900-UpbECiGlrmGsTnJN9+BGXg@public.gmane.org>
2010-05-28 12:33 ` Vincent Diepeveen
[not found] ` <BF3C6199-02BC-415A-B028-E856312FB2DD-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
2010-05-28 13:36 ` Gordan Bobic
[not found] ` <4BFFC6FA.8010208-UpbECiGlrmGsTnJN9+BGXg@public.gmane.org>
2010-05-28 14:31 ` Vincent Diepeveen
[not found] ` <20C856F0-0CEB-45B9-A668-C07C89A7D338-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
2010-05-28 15:36 ` Gordan Bobic
2010-05-28 12:45 ` Vincent Diepeveen
[not found] ` <A3BB0C84-D2BD-4119-9296-0A4D9FC02F19-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
2010-05-28 13:39 ` Gordan Bobic
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=4BFCF55A.80205@bobich.net \
--to=gordan-upbeciglrmgstnjn9+bgxg@public.gmane.org \
--cc=linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 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.