Интересная тема?

То они плотность записи на пластины повышают, то скорость вращения, а тут раз - и рекорд скорости записи можно срубить. Как с куста. И не очень дорого: встроить DSP или что-то подобное в контроллер HDD, сжимать и разжимать "на лету".

Причем очевидно, что при скорости работы нынешних дисков скорость сжатия будет заведомо выше пропускной способности ATA133 - SATA150, про декомпрессию вообще молчу. Причем сжатие может быть как пофайловое, так и просто по кускам отправляемой инфы (но тут сложнее, доступ потом будет не обязательно в том же порядке).

В любом случае, это было бы ЯВНО более эффективно, чем очередная смена протокола и попытка чуть побыстрее раскрутить диск.

Кто-нибудь слышал о подобных планах? И вообще, есть ли против этой идеи возражения какие-то технические?

Hil

1) Представь себе операции с RAR или 7-zip архивами
2) Это равносильно расширению пропускной способности интерфейса ATA/SATA, что на реальное быстродействие всё равно очень слабо влияет

fin Я в первую голову думаю не об интерфейсе на матери, так как это как раз неинтересно (это и без матери уже реализовано софтом). Я думаю о том, что ВНУТРИ HDD данные ПЕРЕД ЗАПИСЬЮ НА ПЛАСТИНУ должны сжиматься, а при считывании - разжиматься. А через SATA путешествовать можно и в разжатом виде. Достоинства? Да простейшие: ПОЛНАЯ совместимость с нынешними протоколами для HDD. А под OS драйвера нужны, просто чтобы правильнее обращаться с количеством свободного места на диске. И то, обойтись можно.

fin
Не совсем, потому как "логически" увеличивается производительность блинов, а не пропускная способность канала... И жать придется посекторно, что почти намертво убьет качество упаковки...

Hil, don't You find the by-file compression on the HDD to be too troublesome? How can HDD know about file system stored on it? Well, one can add support for FAT32, NTFS, ext2fs, ext3fs (and what about Linux swap partition? ). But there are lots of other file systems available. So the HDD will either have to be limited to few file systems, or to have an enourmously complex controller.

So here I agree with STranger, who said that the HDD will have to implement by-sector compression. And, in my opinion this will cause no increase of HDD's capacity.

Hil Во первых как сказал artem_anisimov , что будем делать с разными файловыми системами?
А во вторых, надо в винт добавлять еще один процессор, который будет кодировать данные, и чтоб это было "на лету", процессор нужен не слабый.
Себестоимость винта растет, быстродействие практически не меняется.

Вообще то где-то в новостях проскакивала материнская плата (возможно из новых ABIT MAX), где прилагался малюсенький переходничок для жесткого диска с аппаратным шифрованием данных. Вот это было б действительно зашибись! Вот бы кто сделал REVERSE ENGINEERING и схемку/прошивку выложил!

А про сжатие данных лучше забыть! Зачем!? Только скорость упадет в разы, а проку как такового и нету...

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

Зеленый_Змий
Я не думаю, что в домашних условиях реально что-то сделать с данным девайсом... Также мне непонятно, а ключ шифрования у любого такого девайса одинаковый? Тогда особенной пользы от этого нет... Или генерится по случайному алгоритму для каждого девайса? Тогда при его отказе данные накрываются болшим медным тазом... Или же с помощью специальной утилитки задается? В общем-то логика работы данного девайса ясна... Выделить операцию записи, зашифровать блок данных, передать их винту... Выделить операцию чтения, получить данные с винта, расшифровать, передать их на компьютер... В общем-то, тот же ГОСТовский алгоритм шифрования достаточно легко реализуется с помощью аппаратных девайсов...

Не понял, поясни

Hil Как ты себе представляешь быстрый доступ к произвольному месту диска, если емкость сектора у тебя плавает? Хотя я встречал упоминания о том что IBM реализовывала аппаратное сжатие даже для оперативной памяти "на лету". Но память в этом случае лучше - в ней "дырки" после удалений страниц гораздо проще ликвидировать.

На самом деле, проблем две:
- нафига это надо
и вторая
- как найти автора идеи и пыльный мешок одновременно????


.... если серьезно, то ...
Возможны 2 подхода:
1) {ставится переходная плата} упаковывать исключительно ради скорости, тогда пакуется сектор, а размер сектора = 4Kb
Если мне не изменяет склероз, за одно обращение по BusMaster передается 32Kb - т.е. теряется
смысл.
2) упаковывать данные на самом диске(носителе), а пустующее место:
а) использовать для кодов исправления - выше надежность, но не скорость
б) один track записывать скомпрессированными данными, потом следует логическое представление. На самом деле, там и так логическая адресация.
В таком случае ДИЧАЙШЕ растет фрагментация!! Пример - откуда взять место в середине трека, если степень компрессии уменьшилась? Если это RAM или FLASH проблем нет, хоть всю делай в фрагментах, а механический носитель ...

serj_ На каком таком носителе сектор 4096 байт? Или ты в битах меряешь?
И заметь, выводы мы одинаковые делаем

Нам еще в институте помню говорили, что на винчестере около 100 мб, а "на лету" сжимает программа.