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]
Message-ID: <469D2D911E4BF043BFC8AD32E8E30F5B24AED8@wdscexbe07.sc.wdc.com>
Date:	Mon, 5 Jul 2010 18:49:34 -0700
From:	"Daniel Taylor" <Daniel.Taylor@....com>
To:	<linux-ext4@...r.kernel.org>
Subject: inconsistent file placement

I realize that it is enerally not a good idea to tune
an operating system, or subsystem, for benchmarking, but
there's something that I don't understand about ext[234]
that is badly affecting our product.  File placement on
newly-created file systems is inconsistent.  I can't,
yet, call it a bug, but I really need to understand what
is happening, and I cannot find, in the source code, the
source of the randomization (related to "goal"???).

Disk drive performance for writing/reading large files
is rather sensitive to outer-/inner-diameter cylinder
placement.  When I create the same file multiple times
on newly-created ext[234] file systems on the same disk
partition, I find that it does not consistently occupy
the same blocks.  In fact, there is enough difference in
location to cause real differences in performance from
test to test, which I cannot justify to management.

We are currently on 2.6.32.12, using a 32-bit powerpc.  The
system is booted from tftp and the root file system is NFS
for the test.  The partition used is always the same one,
and it is the only one mounted from the disk.  There is
always exactly one (5G) file created using the same command
"for i in 1 2 3 4 5; do dd if=/hex.txt bs=64K; \
done >>/DataVolume/hex.txt", where /hex.txt is a 1G file
and /DataVolume is the mounted disk partition.

I have tried, as I said, ext[234], and have tinkered with
most of the options, including orlov/oldallocator, and the
behavior doesn't change.  Here's a sample of dumpe2fs
output from three runs, in a diff3:

====
1:51,52c
    44750 free blocks, 65268 free inodes, 2 directories
    Free blocks: 295-45044
2:51,52c
    11990 free blocks, 65268 free inodes, 2 directories
    Free blocks: 295-12284
3:51,52c
    40655 free blocks, 65268 free inodes, 2 directories
    Free blocks: 295-40949
====
1:59,60c
    3794 free blocks, 65280 free inodes, 0 directories
    Free blocks: 65819-65823, 127267-131055
2:59,60c
    36554 free blocks, 65280 free inodes, 0 directories
    Free blocks: 65819-65823, 94507-131055
3:59,60c
    7889 free blocks, 65280 free inodes, 0 directories
    Free blocks: 65819-65823, 123172-131055

Thanks for any help,

Dan
--
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