Hi Stephen,
That's a great point. I recreated the filesystem again, using default
options and then create a directory.
These are some info:
1864 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
# mount /dev/hdb /sam/cache
# ls -ldi /sam/cache/test
11485185 drwxr-xr-x 2 root root 4096 Jul 14 17:39 /sam/cache/test
The directory inode is in the ~701st block group if not mistaken, which
is no where near the beginning of the filesystem.
This looks to me like it had changed from kernel 2.4 time. But is it
still true that any files being created under the directory will still
have the data written into free space in the same block group as the
directory, and onwards?
So, how does it work now? Is a directory randomly placed now even on an
empty file system?
Is there anyway to force it to be created near the beginning of the file
system, thus towards to outermost cylinders?
The application I am working with only use one directory on a file
system, so I don't really care where it is placed. But for performance
testings, like the one versus raw access, it would be nice to test
against file written at the beginning of the filesystem.
Thanks,
...
ling
Stephen C. Tweedie wrote:
Hi,
On Thu, 2006-07-13 at 15:13 -0500, Ling C. Ho wrote:
If I dd the same amount of data from the disk device itself, I get about
18.5s, which matches what hdparm -tT gives me.
Be aware, disks typically have different performance depending on where
the data is, with data on the outermost cylinders getting higher
throughput than data on innermost cylinders (there's constant rotational
velocity for the surface, but the outer tracks are longer so each
rotation carries more data past the heads.)
So all sorts of things like the exact data placement can come into
effect. Are you sure you're using the same bits of the disk for the raw
and filesystem cases?
--Stephen
_______________________________________________
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
