linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 47151] provide a file system block size of 8KB for certain SSDs.
Date: Fri,  5 Oct 2012 18:07:33 +0000 (UTC)	[thread overview]
Message-ID: <20121005180733.CE63F11FB37@bugzilla.kernel.org> (raw)
In-Reply-To: <bug-47151-13602@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=47151


Jeff Moyer <jmoyer@redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmoyer@redhat.com




--- Comment #10 from Jeff Moyer <jmoyer@redhat.com>  2012-10-05 18:07:33 ---
(In reply to comment #8)
> 8K is to be understood instead of the usual 4K as page size (smallest read- and
> writeable entity).

Internal to the device, it's the smallest I/O size.  But the device continues
to export probably a 512 byte logical block size (or, more rarely, a 4k one).

> Eric: I doubt that anyone would file a bug report on it as
> the only effect of using a wrong fs block size will be degraded performance and
> a shortened lifetime of the SSD (nobody would in deed find out about it who
> hasn`t tried it with 8KB block size or heard about disks with page size != 4K).

Given that pretty much all file systems running on Linux and Windows will use a
block size less than or equal to the page size (4k), you can bet that the SSD
vendor took this into account when advertising both the performance of the
drive and the lifetime.  I'll also note that this SSD isn't posing any new
problems.  Consider RAID devices.  They would also like I/O in larger than page
size quantities.  We don't have to provide that in order to get good
performance, though, for a large number of reasons (which vary depending on the
exact hardware and software configuration you're talking about).  Also keep in
mind that the workload you intend to run will play a large role when
determining what file system block size you choose (for example, to avoid
unnecessary wasting of space).

> Feel free to care about it whenever you want as we do not have any users
> requiring it yet (to me for myself this isn`t any issue since I don`t plan to
> use the besaid disk at the time).

If you want to play around with things, try creating a 4k file system with a
stripe width of 2.  Of course, you'd have to have the hardware to try this, and
you don't, nor does anyone looking at this, so the discussion is moot.

The bottom line is that if someone wants to take on the work to get file system
block sizes pushed beyond page size, we're all for it.  Lobbying for this to
get done isn't going to help as much as doing the work or paying someone to do
the work, though.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

  parent reply	other threads:[~2012-10-05 18:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-06 20:34 [Bug 47151] New: provide a file system block size of 8KB for certain SSDs bugzilla-daemon
2012-09-07 15:32 ` [Bug 47151] " bugzilla-daemon
2012-09-07 18:03 ` bugzilla-daemon
2012-09-07 18:07 ` bugzilla-daemon
2012-09-07 18:12 ` bugzilla-daemon
2012-09-29 12:22 ` bugzilla-daemon
2012-10-01 14:50 ` bugzilla-daemon
2012-10-01 14:56 ` bugzilla-daemon
2012-10-05 17:26 ` bugzilla-daemon
2012-10-05 17:30 ` bugzilla-daemon
2012-10-05 18:07 ` bugzilla-daemon [this message]
2012-10-05 18:20 ` bugzilla-daemon
2012-10-10  9:28 ` bugzilla-daemon
2012-10-10  9:36 ` bugzilla-daemon
2012-10-10  9:41 ` bugzilla-daemon
2012-10-10 10:14 ` bugzilla-daemon
2012-10-11 20:54 ` bugzilla-daemon
2012-10-11 20:58 ` bugzilla-daemon

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=20121005180733.CE63F11FB37@bugzilla.kernel.org \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-ext4@vger.kernel.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).