lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri,  5 Oct 2012 18:07:33 +0000 (UTC)
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 47151] provide a file system block size of 8KB for certain
 SSDs.

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


Jeff Moyer <jmoyer@...hat.com> changed:

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




--- Comment #10 from Jeff Moyer <jmoyer@...hat.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ