[Bug 47151] New: provide a file system block size of 8KB for certain SSDs.

[Bug 47151] New: provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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

           Summary: provide a file system block size of 8KB for certain
                    SSDs.
           Product: File System
           Version: 2.5
    Kernel Version: 3.4.6-2.10-default
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: ext4
        AssignedTo: fs_ext4@kernel-bugs.osdl.org
        ReportedBy: estellnb@elstel.org
        Regression: No


Sandisk support says that its 480GB SSDs have a block size of 8KB instead of
the usual 4KB. Thus in order to use that SSD we would have to format with a
block size of 8KB. As SSDs get bigger and bigger it is likely that also other
vendors will sell SSDs with a block size of 8KB. Please look forward to
supporting an ext4 blocksize of 8KB!

# mkfs.ext4 -b 8192 test.disk 
Warning: blocksize 8192 not usable on most systems.
mke2fs 1.42.4 (12-June-2012)
test.disk is not a block special device.
Proceed anyway? (y,n) y
mkfs.ext4: 8192-byte blocks too big for system (max 4096)
Proceed anyway? (y,n) y
Warning: 8192-byte blocks too big for system (max 4096), forced to continue
Discarding device blocks: done                            
Filesystem label=
OS type: Linux
Block size=8192 (log=3)
Fragment size=8192 (log=3)
Stride=0 blocks, Stripe width=0 blocks
1280 inodes, 1280 blocks
64 blocks (5.00%) reserved for the super user
First data block=0
1 block group
65528 blocks per group, 65528 fragments per group
1280 inodes per group

Allocating group tables: done                            
Writing inode tables: done                            

Filesystem too small for a journal
Writing superblocks and filesystem accounting information: done

# mount -o loop test.disk /mnt/
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so
# dmesg | tail
[ 2020.657698] SFW2-INext-DROP-DEFLT IN=eth0 OUT=
MAC=33:33:00:00:00:fb:44:d8:84:61:8c:33:86:dd
SRC=fe80:0000:0000:0000:46d8:84ff:fe61:8c33
DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=227 TC=0 HOPLIMIT=255 FLOWLBL=0
PROTO=UDP SPT=5353 DPT=5353 LEN=187 
[ 2020.657874] SFW2-INext-DROP-DEFLT IN=eth0 OUT=
MAC=33:33:00:00:00:fb:44:d8:84:61:8c:33:86:dd
SRC=fe80:0000:0000:0000:46d8:84ff:fe61:8c33
DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=227 TC=0 HOPLIMIT=255 FLOWLBL=0
PROTO=UDP SPT=5353 DPT=5353 LEN=187 
[ 2020.696054] SFW2-INext-DROP-DEFLT IN=eth0 OUT=
MAC=33:33:00:00:00:fb:44:d8:84:61:8c:33:86:dd
SRC=fe80:0000:0000:0000:46d8:84ff:fe61:8c33
DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=227 TC=0 HOPLIMIT=255 FLOWLBL=0
PROTO=UDP SPT=5353 DPT=5353 LEN=187 
[ 2020.992554] SFW2-INext-DROP-DEFLT IN=eth0 OUT=
MAC=33:33:00:00:00:fb:44:d8:84:61:8c:33:86:dd
SRC=fe80:0000:0000:0000:46d8:84ff:fe61:8c33
DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=431 TC=0 HOPLIMIT=255 FLOWLBL=0
PROTO=UDP SPT=5353 DPT=5353 LEN=391 
[ 2045.224133] SFW2-INext-DROP-DEFLT IN=eth0 OUT=
MAC=33:33:00:00:00:fb:44:d8:84:61:8c:33:86:dd
SRC=fe80:0000:0000:0000:46d8:84ff:fe61:8c33
DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=142 TC=0 HOPLIMIT=255 FLOWLBL=0
PROTO=UDP SPT=5353 DPT=5353 LEN=102 
[ 2188.427869] SFW2-INext-DROP-DEFLT IN=eth0 OUT=
MAC=33:33:00:00:00:fb:00:1b:63:2f:5e:93:86:dd
SRC=fe80:0000:0000:0000:021b:63ff:fe2f:5e93
DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=111 TC=0 HOPLIMIT=255 FLOWLBL=0
PROTO=UDP SPT=5353 DPT=5353 LEN=71 
[ 2188.429149] SFW2-INext-DROP-DEFLT IN=eth0 OUT=
MAC=33:33:00:00:00:fb:00:80:77:d8:ee:7d:86:dd
SRC=fe80:0000:0000:0000:0280:77ff:fed8:ee7d
DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=485 TC=0 HOPLIMIT=1 FLOWLBL=0
PROTO=UDP SPT=5353 DPT=5353 LEN=445 
[ 2192.171020] EXT4-fs (loop0): bad block size 8192
[ 2193.769124] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=
SRC=fe80:0000:0000:0000:02a0:ccff:fed9:b3da
DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=84 TC=0 HOPLIMIT=255 FLOWLBL=0
PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[ 2246.621356] EXT4-fs (loop0): bad block size 8192

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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


Alan <alan@lxorguk.ukuu.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |alan@lxorguk.ukuu.org.uk
         Resolution|                            |WILL_NOT_FIX




--- Comment #1 from Alan <alan@lxorguk.ukuu.org.uk>  2012-09-07 15:32:45 ---
This isn't a bug..... it may be a feature in which case send patches. However
the core Linux kernel code doesn't support a block size larger than the page
size of the hardware (and you'd get memory fragmentation problems if you
changed that).

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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





--- Comment #2 from Elmar Stellnberger <estellnb@elstel.org>  2012-09-07 18:03:21 ---
  Perhaps a file system block size of 8KB and higher should only be supported
if the user boots in an adequate paging mode. PAE paging and IA-32e paging f.i.
support a physical page size of 2MB. This may even be more efficient for
certain usage scenarios (especially with a rich memory accouterment) as the
page table will hereby get smaller.
  Another idea would simply be to keep sufficient chunks of 8KB and guarantee
allocation in 8KB chunks if the allocation area or segment size is being kept a
multiple of 8KB starting at an 8KB aligned address (I don`t think it would be
that hard to manage since most segments are bigger than 4KB and 8KB chunks
could also be used for these 4KB chunked and aligned segments.)

btw.: it was filed as enhancement

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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





--- Comment #3 from Elmar Stellnberger <estellnb@elstel.org>  2012-09-07 18:07:02 ---
i.e. only allow a small part of the memory to hold 4KB fragments. In worst case
we would fall down to an effective emulated page size of 8KB.

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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


Eric Sandeen <sandeen@redhat.com> changed:

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




--- Comment #4 from Eric Sandeen <sandeen@redhat.com>  2012-09-07 18:12:05 ---
(In reply to comment #0)
> Sandisk support says that its 480GB SSDs have a block size of 8KB instead of
> the usual 4KB. Thus in order to use that SSD we would have to format with a
> block size of 8KB.

Do you have one of these devices?  I'd be a little surprised if it's really not
formattable with 4k blocks.  If you have the device, this might be interesting:

# blockdev --getss --getpbsz --getiomin --getioopt --getbsz /dev/sdX

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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





--- Comment #5 from Elmar Stellnberger <estellnb@elstel.org>  2012-09-29 12:22:20 ---
Sorry, I don`t have such a device handy and could not get anyone to directly
attend the report who has.

Veronika B. from support@sandisk.com writes:
>
> The only drive currently produced by SanDisk with 8K alignment is the
> Extreme SSD of 480GB. Only the drives with this capacity will be aligned
> to 8K.
>

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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





--- Comment #6 from Eric Sandeen <sandeen@redhat.com>  2012-10-01 14:50:12 ---
Ok, at this point we have no evidence that larger fs block sizes will be
required for this SSD.  That email from sandisk doesn't really tell us a whole
lot, simply saying "8k alignment" isn't terribly informative.  Is that the
minimum alignment, the physical alignment, etc.  I think someone will need to
get their hands on a device to see what it really advertises.  Scouting around
the web I've not seen any indication that this device has an 8k logical
blocksize; if it did there would surely be some noisy reviews out there about
how it doesn't work on x86 linux today, I think.

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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





--- Comment #7 from Eric Sandeen <sandeen@redhat.com>  2012-10-01 14:56:40 ---
As Alan alluded to, blocks size > page size is not a trivial problem, so this
isn't likely to happen any time soon.  I just wanted to clarify whether a
device was really shipping that would require it for 4k page systems.

Thanks,
-Eric

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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





--- Comment #8 from Elmar Stellnberger <estellnb@elstel.org>  2012-10-05 17:26:56 ---
8K is to be understood instead of the usual 4K as page size (smallest read- and
writeable entity). 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).
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).

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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


Elmar Stellnberger <estellnb@elstel.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WILL_NOT_FIX                |




--- Comment #9 from Elmar Stellnberger <estellnb@elstel.org>  2012-10-05 17:30:55 ---
No, there seem to be plenty of users requiring it: my first search for 'SSD 8K
file system block size' has produced an immediate hit at place #1:
http://forums.gentoo.org/viewtopic-t-935946.html?sid=6b0893c88505b69270c47558ff641326

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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.

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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





--- Comment #11 from Eric Sandeen <sandeen@redhat.com>  2012-10-05 18:20:45 ---
Agreed.  Random people on gentoo forums notwithstanding, I see no evidence that
this device needs help from the kernel to function properly.  All SSDs have
larger structures in use internally, and firmware to manage the fact that they
expect to get smaller IOs from the OS.

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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





--- Comment #12 from Elmar Stellnberger <estellnb@elstel.org>  2012-10-10 09:28:13 ---
Sandisk support does actually not respond any more. I think we can close this
issue as they do not seem to be interested in Linux support.

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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





--- Comment #13 from Elmar Stellnberger <estellnb@elstel.org>  2012-10-10 09:36:28 ---
Oops; my fault; have overlooked the response:

> The 480GB Extreme SSD drive has to be aligned to 8K. It cannot be aligned to 
> smaller blocks, i.e. 4K. This issue will be addressed in the new firmware 
> release, however, we cannot announce any specific time frame regarding when 
> this release is going to happen.
>

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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





--- Comment #14 from Elmar Stellnberger <estellnb@elstel.org>  2012-10-10 09:41:25 ---
i.e. the current drives don`t have such a 4K-emulation. By the time however I
can not say whether other drives of other manufacturers may be affected by the
same issue.

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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


Alan <alan@lxorguk.ukuu.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WILL_NOT_FIX




--- Comment #15 from Alan <alan@lxorguk.ukuu.org.uk>  2012-10-10 10:14:16 ---
I have talked to  folks in the SSD world and the view seems to be

- bigger than 4K block size is not a concern because the real device is just
making up the disk block sizes anyway
- alignment according to the identify data is important (and is a matter for
fdisk etc)
- this isn't particularly likely to change

So I think we should just close this as WONTFIX. Anyone who cares sufficiently
and has a use case should instead submit patches.

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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





--- Comment #16 from Elmar Stellnberger <estellnb@elstel.org>  2012-10-11 20:53:59 ---
> the real device is just making up the disk block sizes anyway
Yes, in our case it would make up a block size of 8KB

> alignment according to the identify data is important 
No, only for HDDs not for SSDs; here the alignment needs to fit
the internal or exposed alignment of the SSD in order not to
ruin it by a 2x or 4x-ing of all read-write cycles

> this isn't particularly likely to change
Yes, folks of any chat channel are not aware of these issues.

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

[Bug 47151] provide a file system block size of 8KB for certain SSDs.

[bugzilla-daemon]

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





--- Comment #17 from Elmar Stellnberger <estellnb@elstel.org>  2012-10-11 20:58:41 ---
The question is whether we need to support these few 8K drives that are out
that do not have a 4K emulation. I believe the Linux support of SSDs is already
very well; f.i. on Win only Windows 7 has a trim mount support (afaik).

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