All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gordan Bobic <gordan-UpbECiGlrmGsTnJN9+BGXg@public.gmane.org>
To: Vincent Diepeveen <diep-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: SSD and non-SSD Suitability
Date: Fri, 28 May 2010 14:39:27 +0100	[thread overview]
Message-ID: <4BFFC78F.10900@bobich.net> (raw)
In-Reply-To: <A3BB0C84-D2BD-4119-9296-0A4D9FC02F19-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>

Vincent Diepeveen wrote:

>>>>>> 1) Modern SSDs (e.g. Intel) do this logical/physical mapping 
>>>>>> internally, so that the writes happen sequentially anyway.
>>>>> Could you explain that, as far as i know modern SSD's have 8 
>>>>> independant channels to do read and writes, which is why they are 
>>>>> having that big read and write speed and can in theory therefore 
>>>>> support 8 threads doing reads and writes. Each channel say using 
>>>>> blocks of 4KB, so it's 64KB in total.
>>>>
>>>> I'm talking about something else. I'm talking about the fact that 
>>>> you can turn logical random writes into physical sequential writes 
>>>> by re-mapping logical blocks to sequential physical blocks.
>>> That's doing 2 steps back in history isn't it?
>>
>> Sorry, I don't see what you mean. Can you elaborate?
> 
> I didn't investigate NILFS, but under all conditions what you want to 
> avoid is some sort of central locking of the file system,
> because if you're proposing all sorts of fancy stuff to the file system 
> whereas you can already do your thing using full bandwidth of the SSD.

Are you actually claiming that you can achieve full write throughput on 
random writes that you can achieve on sequential writes on an SSD? Try 
that with write caches on the drive disabled.

> It really is interesting to have a file system where you do a minimum 
> number of actions to the file system
> so that other threads can do there work there. Any complicated 
> datastructure manipulation that requires central locking
> or other forms of complicated locking will limit other i/o actions.

I agree.

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

      parent reply	other threads:[~2010-05-28 13:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-26 10:18 SSD and non-SSD Suitability Gordan Bobic
     [not found] ` <4BFCF55A.80205-UpbECiGlrmGsTnJN9+BGXg@public.gmane.org>
2010-05-28  6:29   ` 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 [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=4BFFC78F.10900@bobich.net \
    --to=gordan-upbeciglrmgstnjn9+bgxg@public.gmane.org \
    --cc=diep-qWit8jRvyhVmR6Xm/wNWPw@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.