LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (http://www.linuxquestions.org/questions/linux-general-1/)
-   -   Can I change the physical data position manually to increase the performance? (http://www.linuxquestions.org/questions/linux-general-1/can-i-change-the-physical-data-position-manually-to-increase-the-performance-926607/)

Crogge 01-30-2012 07:47 PM

Can I change the physical data position manually to increase the performance?
 
I look currently for a possibility to change the physical position of specific files/folders on my HDDs. The database folder of MySQL should be for example on the fast part of the HDD (Outside). The Server HDDs are connected to a 3ware hardware raid controller (Raid 1).

OS: Ubuntu LTS

MartinStrec 01-31-2012 04:08 AM

Hi!

I'm afraid you've a wrong imagine about physical storage. HDD has its own electronics and software that calculate physical data position and that is responsible for asymmetrical sectors layout on HDD plates. It is nearly impossible to change it in OS level.

see http://en.wikipedia.org/wiki/Disk_storage
http://en.wikipedia.org/wiki/Cylinder-head-sector

Crogge 01-31-2012 11:54 PM

Quote:

Originally Posted by MartinStrec (Post 4589151)
Hi!

I'm afraid you've a wrong imagine about physical storage. HDD has its own electronics and software that calculate physical data position and that is responsible for asymmetrical sectors layout on HDD plates. It is nearly impossible to change it in OS level.

see http://en.wikipedia.org/wiki/Disk_storage
http://en.wikipedia.org/wiki/Cylinder-head-sector

Wrong, partitions are written by default on the "beginning" of the HDD which is the fast part outside of the HDD.

sundialsvcs 02-01-2012 08:14 AM

Notwithstanding that comment, true though it might or might not be, (IMHO...) it simply doesn't matter in the end. Hard drives themselves often have very sophisticated electronics, including on-board caching and the ability to do asynchronous writes, and controller (cards) can be even smarter. Any "speed advantage" that you might imagine getting by virtue of the fact that your data is located 8cm instead of 4cm from the center of the platter are chimerical. Rotational delay is insignificant; seek-time is where you lose it.

Remember, CPUs operate in terms of nanoseconds, buses and so-forth in microseconds, and hard drives still require many milliseconds to do anything. Caches (both in the hardware and in Linux's own buffer pool) are where it's at.

catkin 02-01-2012 11:13 AM

The outside is the fastest for sustained transfer (when caches no longer help) but that is irrelevant if the actual activity occurs in small transfers. The middle is best to minimise seek times but that is irrelevant if the heads spend most of their time where the critical data is anyway.

dugan 02-02-2012 11:10 PM

Quote:

Originally Posted by Crogge (Post 4589981)
Wrong,

Obviously. I mean, the very existence of disk defragmenters disproves this.

Anyway, the solution seems pretty obvious to me. Wipe the drive, and restore the parts that need to go onto the fastest parts of the drive first. The disk controller will write that to the fastest part of the drive. Then continue with what needs to go to the next fastest part. And so on.

Setting up a partition at the front of the drive for fast data access should work too.

chrism01 02-03-2012 12:53 AM

Personally I agree with sundialsvcs, I think the OP is being extremely optimistic.
I'd also like to see a citation for
Quote:

restore the parts that need to go onto the fastest parts of the drive first. The disk controller will write that to the fastest part of the drive
Quite frankly I doubt it is that predictable with modern tech, not forgetting the OP is using a RAID, not a single disk.

If I was the user, I would want to profile the performance to see where the actual bottleneck is.
Given we're talking an RDBMS based system, it's often the lack of or incorrect indexes in the DB that is the issue.

dugan 02-03-2012 01:18 AM

Quote:

Originally Posted by chrism01 (Post 4592468)
I'd also like to see a citation for

It's covered in Andrew Tanenbaum's "Modern Operating Systems". Due to the way hard drives work, it's obvious that all "modern tech" hard disks do indeed still work this way (except for SSDs, of course). The fact that it's a RAID does not change this; the RAID controller will start writing from the outside edges of each drive, then work its way inwards.

If by "citation" you just meant some pages where this information appears, here are some that showed up in a google search:

www.pcguide.com/ref/hdd/geom/tracks_ZBR.htm
http://www.passmark.com/support/perf...st_results.htm
http://forums.anandtech.com/showthread.php?t=415000
http://www.nvnews.net/vbulletin/showthread.php?t=165018

Now, that said:

Quote:

Given we're talking an RDBMS based system, it's often the lack of or incorrect indexes in the DB that is the issue.
This is probably actually the real problem.

jefro 02-04-2012 06:17 PM

The outside may be relatively faster to the head in terms of mph or so. The problem is that the drive heads have to keep going back to the source to tell where the next block is. I think to save head movements since they are the slowest we now use the middle of the disk to hold partition and file location and apply data to both sides of the middle out. The stuff posted above is like it was 20 years ago.

H_TeXMeX_H 02-05-2012 05:14 AM

I think sparse defragmenting would help more than worrying about the outside or the inside of the disk. XFS has such a defragmenter, I also wrote a script that can do it on filesystems that supports extents, it is on my site.


All times are GMT -5. The time now is 04:36 AM.