Что такое «начало диска» или где создать swap?

Потому, что нефиг всякую фигню слушать.

Оптимизацию системы начинают не с размещения разделов по диску и выноса свапа в его начало (что, кстати, НЕПРАВИЛЬНОЕ решение - учите теорвер, понятие случайной величины и ее матожидания, и пребудет с вами просветление в осознании того, что лучшую среднюю производительнось выбивают из середины диска), а с отключения лишних сервисов и добивки памяти до состояния "шоб не свапилось".

а как тогда нужно разбивать винч?

покажи свой df -h и скажи где у тебя своп ;)

Чем "первее" раздел на диске тем быстрее с него считывается информация. 
linux:~ # hdparm -i /dev/hda
/dev/hda:
 Model=ST380011A, FwRev=3.06, SerialNo=5JVZ127F
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156295279
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:
 * signifies the current active mode
linux:~ # hdparm -t /dev/hda1
/dev/hda1:
 Timing buffered disk reads:  178 MB in  3.02 seconds =  58.89 MB/sec
linux:~ # hdparm -t /dev/hda2
/dev/hda2:
 Timing buffered disk reads:  154 MB in  3.03 seconds =  50.87 MB/sec
linux:~ # hdparm -t /dev/hda3
/dev/hda3:
 Timing buffered disk reads:  132 MB in  3.01 seconds =  43.86 MB/sec
linux:~ # hdparm -t /dev/hda4
/dev/hda5:
 Timing buffered disk reads:  132 MB in  3.02 seconds =  43.77 MB/sec
linux:~ # hdparm -t /dev/hda6
/dev/hda6:
 Timing buffered disk reads:  132 MB in  3.02 seconds =  43.69 MB/sec
linux:~ # hdparm -t /dev/hda7
/dev/hda7:
 Timing buffered disk reads:  116 MB in  3.01 seconds =  38.48 MB/sec
linux:~ # hdparm -t /dev/hda8
/dev/hda8:
 Timing buffered disk reads:  106 MB in  3.05 seconds =  34.75 MB/sec
linux:~ #    

З.Ы.:Оптимизация начинается с апгрейда серого вещества... =)

тебе это разбиение не даст желаемого эффекта, вообще никакого не даст.

Мне кажется или на современных винтах эти попытки угадать начало диска просто бессмысленны?

имхо если у тебя свопование происходит параллельно с другим дисковым IO то проиграешь в скорости по-любому.

лучше уж тогда отдельный диск под это дело выделить

про память -- соглашусь.

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

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

> Чем "первее" раздел на диске тем быстрее с него считывается информация.

Прекрати нести фигню. Ну не важна скорость ее считывания - НЕ ВАЖНА! Самой времязатратной операцией является позиционирование головки на нужную дорожку, и чтобы получить наилучшее время отклика, самые часто используемые разделы должны быть расположены рядом для минимизации этого времени.

Посему всем немедленно учить математическую статистику и теорию вероятности, и вообще получить высшее образование и изучить теорвер, алгебру, геометрию, матлогику и дискретку :-)

2no-dashi: ты говоришь про время доступа к секторам свопа, а товарищч loge - про скорость чтения данных с своп-раздела. Оба параметра важны, но, как я понял, они противоречат.

> а товарищч loge - про скорость чтения данных с своп-раздела

Со свапа весьма редко идет линейное чтение - а уж если говорить о реальной работе, когда кроме свопа еще какое-нибудь приложение активно дисками "шуршит" - то дело вообще пахнет керосином. Ради интереса, как-то раз провел тест на чтение в произвольном порядке (seek в позицию выданную random и чтение 16КБайт). Так вот на IDE всего при трех таких процессах получить в результате реальную скорость чтения (объем данных поделенный на время теста) выше чем 500KБайт в секунду уже практически невозможно.