Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This is an obscure question, I know. I'm trying to do some performance testing of some disks on a Linux box. I'm getting some inconsistent results, running the same test on the same disk. I know that disks have different performance depending on which part of the disk is being accessed. In particular, reads and writes to the outside of the disk have much higher throughput than reads and writes to the inside part of the disk, due to near-constant data density and constant rotational speed.

I'd like to see if my inconsistencies can be attributed to this geometry-induced variance in throughput. Is it possible, using existing tools, to find out where on the disk a file has been placed?

If not, I suppose I can write something to directly seek, read, and write to the device file itself, bypassing (and destroying) the filesystem, but I'm hoping to avoid that. I'm currently using ext4 on a 3.0 kernel (Arch Linux, if it matters), but I'm interested in techniques for other filesystems as well.

share|improve this question
1  
who says files are in one place ? If they get fragmented (which they usually do) they can end up all over. –  Sirex Sep 9 '11 at 6:31
    
Absolutely. But they're still someplace :-) And in my particular case, writing files to a newly-created filesystem, they're quite likely to be (mostly) unfragmented. –  Rick Koshi Sep 9 '11 at 9:24
add comment

3 Answers

up vote 3 down vote accepted

You could use debugfs for this:

debugfs -R "stat ~/myfile" /dev/hda1

Change the hard/partition drive accordingly and make sure the drive is unmounted. You will get a list with all the blocks used:

BLOCKS:
(0):1643532
TOTAL: 1
share|improve this answer
1  
This is perfect, thanks. I'm not sure why you said to make sure the drive is unmounted, though. According to the manual page, debugfs opens in read-only mode by default, so this command should be completely safe even on an active filesystem. It might provide questionable results if the queried file is being actively changed at the time, of course, but no other problems should result. Have I missed something? –  Rick Koshi Sep 9 '11 at 9:03
    
No, you are right. It's more of a 'best practice' then a must. If you are doing it on an active filesystem, files may change etc. –  Bart De Vos Sep 9 '11 at 10:45
add comment

You can use the FIBMAP ioctl, as exemplified here, or using hdparm:

/ $ sudo /sbin/hdparm --fibmap /etc/X11/xorg.conf

/etc/X11/xorg.conf:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0    1579088    1579095          8
share|improve this answer
    
Unfortunately, nothing output by stat is the information I need. Size in bytes and blocks, inode number, permissions... None of these reflect which blocks contain the file's data. As an example, my test files (which are all the same size) all show exactly the same data, except for inode number and access/modification times. –  Rick Koshi Sep 9 '11 at 6:37
    
Yes, you are right, I'm sorry, I didn't read properly. I changed my answer to stg more appropriate. –  huitseeker Sep 9 '11 at 7:32
    
hdparm does indeed give me what I need, and in a somewhat more readable format than debugfs. I had to go find it, though, since it's not installed (on Arch Linux) by default. debugfs is part of e2fsprogs (same package that gives us mkfs and fsck), so is installed by default. –  Rick Koshi Sep 9 '11 at 9:22
add comment

This thread may give you some insight into ext4 file placement algorithm.

debugfs has a bmap function, which seems to give the data you want. You should be able to give it consecutive blocks of a file and get the physical block numbers.

share|improve this answer
1  
Thanks for the pointer to the thread about ext4 file placement. That was enlightening. :-) –  Rick Koshi Sep 9 '11 at 9:26
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.