проблема с диском 160 ГБ - lba48

[a550ee]

Добрый день!
Есть жесткий диск размером 160 Гб (вестерн) и есть материнская плата, с биосом, к-ый не поддерживает lba48.
Под виндами винт выглядел 137 Гб -ым, после установки ПО от разработчика железа (Data Lifeguard) проблема решалась.

Сейчас живу под федорой (ядро 2.6.16-1.2080_FC5) и взялся создать на этом диске один раздел ext3: подозревал, что, возможно, проблема снова напомнит о себе, но такой засады не ожидал.
Создаю primary раздел с помощью parted размером ровно 160 ГБ, файловую систему с помощью mkfs.ext3 и получаю диск размером 145 Гб, который, в добавок, уже на 5% заполнен и свободного места на нем 139(!!!) Гб.

Объясните, пожалуста, в чем тут дело и как с этим бороться.

[Shura]

А что если БИОС обновить?

[alv]

А что если БИОС обновить?

это во-первых
во-вторых, 5% - это, если не изменяет память, именно то, что Линукс по молчанию резервирует под системные нужды
в третьих - если перечитать 160 липовых гигабайт, в которых считают производители, в гигабайты правильные - сколько получится?
(самому считать лень)

[a550ee]

А что если БИОС обновить?

это во-первых
во-вторых, 5% - это, если не изменяет память, именно то, что Линукс по молчанию резервирует под системные нужды
в третьих - если перечитать 160 липовых гигабайт, в которых считают производители, в гигабайты правильные - сколько получится?
(самому считать лень)

1. Биос обновлен до последней официальной версии прошивки.
2. Насчет 5% процентов, спасибо, успокоили
3. Если пересчитать коммерческие гигабайты в настоящие, то получится 152 Гб, но никак не 145.

[alv]

3. Если пересчитать коммерческие гигабайты в настоящие, то получится 152 Гб, но никак не 145.

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

[Bolverk]

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

кстати, те 5% - они на самом деле не потеряны, их просто дисковые утилиты не видят, и не могут использовать обычные юзеры
но руту, если файловая система переполнена, они доступны для аварийно-спасательных работ (собственно, это и есть их назначение)

а я вот не уверен, есть ли такое на ext3. На других ФС это 1) служебная разметка, большой винт - много уходит на разметку; 2) журнал, тем более на ext3, который хранит не только служебную информацию, но и в какой-то мере содержание файлов.

[Poor Fred]

Хочу добавить ко всему, что БИОС тут вообще не при делах. Никсы, впрочем и как Винды линейки НТ, обращаются к железу напрямую. На одном из компов (Р-1 200Мгц) БИОС видел диск размером только 8 гигов, хотя реально был 60. Однако Фря все правильно определила и разметила.

[Michael]

А что по поводу размера говорит hdparm -I ?

[Bolverk]

оффтопик отодрал, продолжать там
1000 vs. 1024

[VAA]

Поскольку у меня тоже диск 160 ГБ, заинтересовался, а как у меня?

Для начала распечатал таблицу разделов fdisk-ом. Сложил размеры четырех основных разделов (в этой таблице есть данные как для каждого из первичных разделов, так и для составляющих его вторичных). получилось:
156 280 286 блоков по 1024 байта, что составляет
160 031 012 864 байта. Как раз те 160 ГБ, как они считают, десятичных гигабайт..

Потом распечатал размеры разделов командой df и просуммировал 12 разделов:
153 385 658 блоков по 1024 байта, что составляет
157 066 913 792 байта.

Когда при установке разбивал пустой диск fdisk-ом от Win98 - он видел только первые 65 десятичных ГБ. Потом Win 2000 - 131 десятичный ГБ. Линукс увидел все.

Маленькая хитрость, которую я при этом понял: создавая разделы под виндовс надо использовать чуть меньше пространства, чем он видит. Иначе конец раздела будет оформлен некорректно , что может помешать правильно разбить на разделы оставшееся пространство уже даже линуксом.

P.S. А мне понравилось название "коммерческий гигабайт"

P.P.S. По моим подсчетам получается 160 "коммерческих" ГБ = 149 нормальных двоичных,
считая что 1 ГБ = 1024 * 1024 * 1024 байт.