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-next>] [day] [month] [year] [list]
Date:	Sun, 20 Jul 2014 11:47:06 -0700
From:	"Linda A. Walsh" <lkml@...nx.org>
To:	Linux-Kernel <linux-kernel@...r.kernel.org>
Subject: Howto tell kernel to use 4096 as granularity & minimum size?

I have a hard disk with a "512e" sector size: emulated 512, really 4096.

The disk returns a 512-byte size to drivers for compatibility.

I can partition the disk and setup the allocation size
to 4096, but I'd like to tell the kernel to use a
virtual-size of 4096 for the sector as an additional
performance 'hint', so nothing will even try to use
smaller i/o's than that.

However, this doesn't seem to work ("# prompt" does mean root):

/sys/block/sdd/queue#   echo 4096 >minimum_io_size    
bash: minimum_io_size: Permission denied

I realize this is probably implemented as a R-O value,
but it there a reason it needs to be if an admin
wants to increase it to a multiple of an emulated
I/O size so as to have it represent the physical
sector size?

I.e. if the "/sys" code was patched to allow modification
of this variable, would it work for the purpose
I am describing (i.e. ignoring emulated 512 size and
using the real 4096 size as a minimum (I wouldn't
intend or want this to affect the sector# addressing,
which would still be done using 512B sector blocks.

Thanks!


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ