теоретически, я думаю, да, разница должна быть, т.к. разделы физически расположены на разном расстоянии от центра вращения блинов.

своп рекомендуют вообще делать на sda1 разделе - хотя не думаю что разница будет н глаз заметна

ну как бы разделы будут у тебя располагаться на разном расстоянии от центра диска, угловая скорость у разных дорожек будет разная и скорость доступа соответсвенно тоже.

>Зависит ли скорость работы с данными на hdd от количества разделов.

От количества разделов думаю никак не зависит - посмотри вывод команды free, там есть -/+ buffers/cache - так вот думаю таблицы разделов это первое что там кэшируется. От физического размещения на диске естественно зависит и очень сильно - чем ближе к внешнему краю блинов тем выше линейная скорость, там больше секторов размечено чем у центра и обычно разница в скорости чтения раза в полтора-два отличается.

> там больше секторов размечено чем у центра и обычно разница в скорости чтения раза в полтора-два отличается.

Че-то мне казалось, что полтность записи "бит на градус" не зависит от расстояния до оси... Вот SCSI всегда были быстрее IDE (за счет переупорядочивания запросов)... И еще... предлагаю обсудить скорость работы файловых систем :-) По моему от этого гораздо больше зависит...

Спасибо за ответы.

А как можно посчитать, падения производительности - в зависимости от "расстояния" (количества секторов) от центра к краю блина?.

>Че-то мне казалось, что полтность записи "бит на градус" не зависит от расстояния до оси...

Ключевое слово тут "казалось" :) На внешних дорожках физически секторов больше чем на внутренних - сам подумай, зачем терять драгоценное место если можно увеличить емкость чуть ли не в разы ?

>предлагаю обсудить скорость работы файловых систем :-)

А чего тут обсуждать ? reiser4 с компрессией делает всех, если бы не семейные обстоятесльства отца-создателя, думаю через пару лет ос linux могла бы обладать лучшей из существующих ФС.

>А как можно посчитать, падения производительности - в зависимости от "расстояния" (количества секторов) от центра к краю блина?

нормальный тест для hdd строит такие графики.

можешь наваять с попмощью dd и gnuplot, только не забывай про то, что у жёсткого диска есть кэш.

можно извратиться и нарезать жёсткий диск разделов на 12 и на каждый использовать hdparm

можно тестировать с дма и без и т.д.

>А как можно посчитать, падения производительности

Зачем считать - все без нас уже сделано :) Есть утилиты которые это делают в автоматическом режиме и рисуют полную карту диска, под вендой их дофига, mhdd можно тем же посмотреть.

>ос linux могла бы обладать лучшей из существующих ФС.

а как же супа-дупа zfs? :)

hdparm -tT /dev/sda1

/dev/sda1: Timing cached reads: 11486 MB in 2.00 seconds = 5749.96 MB/sec Timing buffered disk reads: 326 MB in 3.02 seconds = 108.07 MB/sec

hdparm -tT /dev/sda10

/dev/sda1: Timing cached reads: 12584 MB in 2.00 seconds = 6299.42 MB/sec Timing buffered disk reads: 326 MB in 3.02 seconds = 54.24 MB/sec

Получилось скорость упала в два раза.

>Получилось скорость упала в два раза.

судя по числам, да

> ос linux могла бы обладать лучшей из существующих ФС.

У ос линукс ещё как бы есть такой шанц: http://btrfs.wiki.kernel.org/index.php/Main_Page

>http://btrfs.wiki.kernel.org/index.php/Main_Page

Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized.

рейзер наше всё

Чем ближе раздел к началу диска тем скорость больше. Между началом и концом разница в скорости чтения непрерывного участка где-то 2 раза

А разве отдельный раздел для свопа не самый быстрый вариант?

> своп рекомендуют вообще делать на sda1 разделе

Сорри, но это чушь полная. В реальной жизни, самый существенный прирост (ну не считая распараллеливания четния) получается в ситуации, когда наиболее часто используемые данные сгруппированы и лежат рядом. То есть в общем случае, правильней всего выкладывать часто используемые данные на середину блина, а редко используемые - к краю блина.

Мне кажется, нонче нельзя нормально предсказать, куда эти данные расположатся. Электроника шибко вумная наступила.

Фик знает - видимо у всех жизнь разная :) На серверах это может подходит - там головка летает вдоль всего диска постоянно - в центре она конечно чаще всего бывает, а на десктопе все наоборот - своп в наше время как правило вообще уже не нужен, бинарники лучше держать в начале диска где их быстрей всего прочитать (потом они уже все равно закешированы и к диску обращения нет) а для всего остального фиолетово где лежать :)

Зато есть в жизни каждого ползователя pc такая глава : Когда кончается оперативка. К слову хрюша в таких случаях тормозит но не зависает намертво и надолго, невпример линуксу.

>Зато есть в жизни каждого ползователя pc такая глава : Когда кончается оперативка.

За всех не надо говорить - у меня такого никогда не случалось :) да и своп я всегда оставляю для засыпания.

>К слову хрюша в таких случаях тормозит но не зависает намертво и надолго

Даже когда место на диске заканчивается ?

>Даже когда место на диске заканчивается ?

Арч, когда в виртуалке закончилось место на диске так и не очнулся. А хрюшку я до такого состояния вообще не доводил.

Случай из жизни: ехал я как-то в поезде в купе со мной ехал мужичек, общительный такой, с нами девушка там еще была и вот решил этот мужичек ее развлечь. Счас говорит я вам кино класное покажу - достал ноутбук там у него селерон какойто памяти 256 метров и виста :) В общем он два раза на enter нажал в тоталкомандере на фильме - короче две копии запустилось медиаплэера. Кино мы так и не посмотрели, перезагружаться через отключение питания он испугался потому что боялся потерять какую-то базу данных, гдето через полчаса у него акум в таком режиме сдох и ноут сам вырубился :) Мужичек весь перепугался - но дело свое сделал, девушку он развлек, она потом часа два над ним хихикала :)

>Счас говорит я вам кино класное покажу - достал ноутбук там у него селерон какойто памяти 256 метров и виста :) В общем он два раза на enter нажал в тоталкомандере на фильме - короче две копии запустилось медиаплэера. Кино мы так и не посмотрели

Кино какраз вы и посмотрели, но не осознали. Медиаплеер даже на хрюше с 512 памяти (Athlon 64 2.4GHz) и одним фильмом вызывает тихую панику и желание его прибить пока он не повесился сам и не повесил комп.

В реальной жизни скорость чтения и записи в начале диска наибольшая, поэтому и рекомендуют там располагать своп

>А как можно посчитать, падения производительности - в зависимости от "расстояния" (количества секторов) от центра к краю блина?.

По формуле, v=w*r, где w - угловая скорость, r - радиус(расстояние от центра блина)

>326 MB in 3.02 seconds = 54.24 MB/sec

ето как?

Дада, кстати :) Кто-то где-то написал неправильную цифру :-)

По теме - правильно сказал г-н Шимон. Сейчас, создав sda1, я бы не был сильно уверен, что он будет в начале диска.

Тестит такой был. Прогоняешь по диску, и график получаешь зависимость скорости чтения/записи от номера чилиндра.

Это теоретически. Номера чилиндров и головок уже давно виртуальные.

Re^2: [чо то там] HDD и производительность.

> На внешних дорожках физически секторов больше чем на внутренних - сам подумай, зачем терять драгоценное место если можно увеличить емкость чуть ли не в разы ?

Где-то читал в своё время, что на внешних дорожках наоборот больше размер кластера, и информацию надежнее хранить на них, а не на внутренних. Правда, нет ли, кому верить не знаю.

> Сейчас, создав sda1, я бы не был сильно уверен, что он будет в начале диска.

fdisk вроде как показывает где раздел физически расположен.
например :

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        3862    31018648+   7  HPFS/NTFS
/dev/sda2            3863        6293    19527007+  83  Linux
/dev/sda3           14542       14593      415800   82  Linux swap / Solaris
/dev/sda4            6294       14541    66252060   83  Linux

Нихрена он не показывает. Все давно виртуально.

В принципе это совершенно ни на что не виляет. Например есть разделы:

sda1 sda2 sda3

Рассмотрим 2 варианта:

1) Свап - sda1, головка находятся по середине блина, на разделе sda2, нужно считать что-то из свапа: головка идёт ниже, и читает раздед sda1

2) Свап - sda3, головка на sda2, что-бы считать что-то из свапа, нужно подняться к разделу sda3

Итого: разницы во времени не будет. А вот если головка на 1-м разделе, а свап на 3-м, тогда может какое-то замедление и будет.

Ну это в случае, что номер раздела = порядковому номеру, сяитая от контроллера головок, т.е от начала блина

>Нихрена он не показывает. Все давно виртуально.

Все он нормально показывает. Если не веришь - запусти любой тест и увидишь что скорость чтения-записи сектора при lba напрямую зависит от его номера - чем меньше номер тем выше скорость. Если считаешь что это делается искусственно то назови хоть одну причину зачем нужно производителям заморачиваться на такое.

Чисто практически - длина окружности L=2пR. При разнице в радиусе в 2 раза и одинаковой плотности на внешних дорожках размещается в два раза больше секторов -> за один оборот диска на внутренних дорожках читается в два раза меньше секторов чем на внешних т.е. скорость чтения секторов на внешних дорожках в два раза больше.

lba скрывает внутреннюю структуру диска при этом снимает ограничение на его объем. При lba не нужно иметь дурацкие пользовательские утилиты которые метят бэды и лопухов которые с умным видом якобы ремонтируют диск - этим занимается система автоматического самоконтроля (дада - тот самый смарт, он не только лапшу вешает но и самостоятельно делает ремап подозрительных блоков) при этом для внешнего мира логические номер секторов остается теми же.