All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.