Сообщение Re[9]: Будущее десктопа от 24.02.2017 23:10
Изменено 24.02.2017 23:12 vsb
Re[9]: Будущее десктопа
Здравствуйте, CreatorCray, Вы писали:
vsb>>2. Гарантированная целостность ФС при нормально работающем оборудовании и потере питания без длительных проверок при загрузке. Также контроль целостности файлов и метаданных даже при сбоящем оборудовании (контрольные суммы).
CC>За это придётся платить скоростью и местом.
Не придётся. Контрольная сумма считается на много порядков быстрей, чем ввод-вывод и занимает на много порядков меньше места.
vsb>>3. Абстракция от хранилищ, множество разделов, raw-разделы, мгновенное изменение размера любого раздела. Т.е. поставил я новый хард на 4 ТБ в компьютер, добавил его в пул, поменял размер /home на +4ТБ и всё, при этом все операции моментальные.
CC>Моментально ничего не бывает, за всё придётся чем то заплатить.
При правильной организации структур данных бывает.
vsb>>5. Сжатие (настраиваемое), шифрование.
CC>Сжатие не нужно и скорее вредно. Шифрование ОК.
Почему это сжатие не нужно и скорее вредно? Сжатие в 99% случаев как раз таки нужно, поскольку позволяет хранить больше на том же месте на халяву (опять же потому, что при правильно выбранных алгоритмах скорость сжатия/разжатия на много порядков больше скорости ввода/вывода). В типичной файловой системе сжимается достаточно много файлов.
vsb>>6. Поддержка RAID (т.е. RAID должен быть реализован в ФС, не на другом уровне).
CC>Нахрена RAID внутри FS?
vsb>>7. Поддержка быстрых кеширующих хранилищ, например небольшой быстрый SSD перед большими HDD, естественно полностью прозрачно для пользователя.
CC>Просто ставь большой SSD и не морочь людям голову.
Ну когда большой SSD будет стоить столько же, сколько стоит большой HDD, соглашусь. Хотя скорее всего и тогда будут разные диски с разными скоростями и ценой. А пока что у HDD нет конкурентов.
vsb>>8. Тут спорно, мне это пока не было нужно, но хотелось бы иметь: автоматическая дедупликация, т.е. поиск одинаковых блоков и удаление дубликатов.
CC>Это медленно, дорого и на практике редко когда полезно.
Редко, но метко, как говорится.
vsb>>9. Возможность организовать дубликат на удалённом хосте, т.е. все изменения идут по сети на удалённый хост и применяются там, таким образом там будет идентичная ФС.
CC>Зачем это в FS?
Потому, что только ФС может сделать это эффективно, она знает точно всё, что происходит с файлами. Например я открыл 20-гигабайтный файл, сделал seek на середину и поменял 10 байтов. По факту изменился 1 блок (4096 Б), который достаточно переслать по сети для синхронизации. Если же пользоваться какими-то внешними утилитами, им как минимум придётся по всему файлу считать какие-то чексуммы и тд, гораздо сложней реализация и гораздо медленней будет работать.
vsb>>2. Гарантированная целостность ФС при нормально работающем оборудовании и потере питания без длительных проверок при загрузке. Также контроль целостности файлов и метаданных даже при сбоящем оборудовании (контрольные суммы).
CC>За это придётся платить скоростью и местом.
Не придётся. Контрольная сумма считается на много порядков быстрей, чем ввод-вывод и занимает на много порядков меньше места.
vsb>>3. Абстракция от хранилищ, множество разделов, raw-разделы, мгновенное изменение размера любого раздела. Т.е. поставил я новый хард на 4 ТБ в компьютер, добавил его в пул, поменял размер /home на +4ТБ и всё, при этом все операции моментальные.
CC>Моментально ничего не бывает, за всё придётся чем то заплатить.
При правильной организации структур данных бывает.
vsb>>5. Сжатие (настраиваемое), шифрование.
CC>Сжатие не нужно и скорее вредно. Шифрование ОК.
Почему это сжатие не нужно и скорее вредно? Сжатие в 99% случаев как раз таки нужно, поскольку позволяет хранить больше на том же месте на халяву (опять же потому, что при правильно выбранных алгоритмах скорость сжатия/разжатия на много порядков больше скорости ввода/вывода). В типичной файловой системе сжимается достаточно много файлов.
vsb>>6. Поддержка RAID (т.е. RAID должен быть реализован в ФС, не на другом уровне).
CC>Нахрена RAID внутри FS?
vsb>>7. Поддержка быстрых кеширующих хранилищ, например небольшой быстрый SSD перед большими HDD, естественно полностью прозрачно для пользователя.
CC>Просто ставь большой SSD и не морочь людям голову.
Ну когда большой SSD будет стоить столько же, сколько стоит большой HDD, соглашусь. Хотя скорее всего и тогда будут разные диски с разными скоростями и ценой. А пока что у HDD нет конкурентов.
vsb>>8. Тут спорно, мне это пока не было нужно, но хотелось бы иметь: автоматическая дедупликация, т.е. поиск одинаковых блоков и удаление дубликатов.
CC>Это медленно, дорого и на практике редко когда полезно.
Редко, но метко, как говорится.
vsb>>9. Возможность организовать дубликат на удалённом хосте, т.е. все изменения идут по сети на удалённый хост и применяются там, таким образом там будет идентичная ФС.
CC>Зачем это в FS?
Потому, что только ФС может сделать это эффективно, она знает точно всё, что происходит с файлами. Например я открыл 20-гигабайтный файл, сделал seek на середину и поменял 10 байтов. По факту изменился 1 блок (4096 Б), который достаточно переслать по сети для синхронизации. Если же пользоваться какими-то внешними утилитами, им как минимум придётся по всему файлу считать какие-то чексуммы и тд, гораздо сложней реализация и гораздо медленней будет работать.
Re[9]: Будущее десктопа
Здравствуйте, CreatorCray, Вы писали:
vsb>>2. Гарантированная целостность ФС при нормально работающем оборудовании и потере питания без длительных проверок при загрузке. Также контроль целостности файлов и метаданных даже при сбоящем оборудовании (контрольные суммы).
CC>За это придётся платить скоростью и местом.
Не придётся. Контрольная сумма считается на порядки быстрей, чем ввод-вывод и занимает на много порядков меньше места.
vsb>>3. Абстракция от хранилищ, множество разделов, raw-разделы, мгновенное изменение размера любого раздела. Т.е. поставил я новый хард на 4 ТБ в компьютер, добавил его в пул, поменял размер /home на +4ТБ и всё, при этом все операции моментальные.
CC>Моментально ничего не бывает, за всё придётся чем то заплатить.
При правильной организации структур данных бывает.
vsb>>5. Сжатие (настраиваемое), шифрование.
CC>Сжатие не нужно и скорее вредно. Шифрование ОК.
Почему это сжатие не нужно и скорее вредно? Сжатие в 99% случаев как раз таки нужно, поскольку позволяет хранить больше на том же месте на халяву (опять же потому, что при правильно выбранных алгоритмах скорость сжатия/разжатия на порядки больше скорости ввода/вывода). В типичной файловой системе сжимается достаточно много файлов.
vsb>>6. Поддержка RAID (т.е. RAID должен быть реализован в ФС, не на другом уровне).
CC>Нахрена RAID внутри FS?
vsb>>7. Поддержка быстрых кеширующих хранилищ, например небольшой быстрый SSD перед большими HDD, естественно полностью прозрачно для пользователя.
CC>Просто ставь большой SSD и не морочь людям голову.
Ну когда большой SSD будет стоить столько же, сколько стоит большой HDD, соглашусь. Хотя скорее всего и тогда будут разные диски с разными скоростями и ценой. А пока что у HDD нет конкурентов.
vsb>>8. Тут спорно, мне это пока не было нужно, но хотелось бы иметь: автоматическая дедупликация, т.е. поиск одинаковых блоков и удаление дубликатов.
CC>Это медленно, дорого и на практике редко когда полезно.
Редко, но метко, как говорится.
vsb>>9. Возможность организовать дубликат на удалённом хосте, т.е. все изменения идут по сети на удалённый хост и применяются там, таким образом там будет идентичная ФС.
CC>Зачем это в FS?
Потому, что только ФС может сделать это эффективно, она знает точно всё, что происходит с файлами. Например я открыл 20-гигабайтный файл, сделал seek на середину и поменял 10 байтов. По факту изменился 1 блок (4096 Б), который достаточно переслать по сети для синхронизации. Если же пользоваться какими-то внешними утилитами, им как минимум придётся по всему файлу считать какие-то чексуммы и тд, гораздо сложней реализация и гораздо медленней будет работать.
vsb>>2. Гарантированная целостность ФС при нормально работающем оборудовании и потере питания без длительных проверок при загрузке. Также контроль целостности файлов и метаданных даже при сбоящем оборудовании (контрольные суммы).
CC>За это придётся платить скоростью и местом.
Не придётся. Контрольная сумма считается на порядки быстрей, чем ввод-вывод и занимает на много порядков меньше места.
vsb>>3. Абстракция от хранилищ, множество разделов, raw-разделы, мгновенное изменение размера любого раздела. Т.е. поставил я новый хард на 4 ТБ в компьютер, добавил его в пул, поменял размер /home на +4ТБ и всё, при этом все операции моментальные.
CC>Моментально ничего не бывает, за всё придётся чем то заплатить.
При правильной организации структур данных бывает.
vsb>>5. Сжатие (настраиваемое), шифрование.
CC>Сжатие не нужно и скорее вредно. Шифрование ОК.
Почему это сжатие не нужно и скорее вредно? Сжатие в 99% случаев как раз таки нужно, поскольку позволяет хранить больше на том же месте на халяву (опять же потому, что при правильно выбранных алгоритмах скорость сжатия/разжатия на порядки больше скорости ввода/вывода). В типичной файловой системе сжимается достаточно много файлов.
vsb>>6. Поддержка RAID (т.е. RAID должен быть реализован в ФС, не на другом уровне).
CC>Нахрена RAID внутри FS?
vsb>>7. Поддержка быстрых кеширующих хранилищ, например небольшой быстрый SSD перед большими HDD, естественно полностью прозрачно для пользователя.
CC>Просто ставь большой SSD и не морочь людям голову.
Ну когда большой SSD будет стоить столько же, сколько стоит большой HDD, соглашусь. Хотя скорее всего и тогда будут разные диски с разными скоростями и ценой. А пока что у HDD нет конкурентов.
vsb>>8. Тут спорно, мне это пока не было нужно, но хотелось бы иметь: автоматическая дедупликация, т.е. поиск одинаковых блоков и удаление дубликатов.
CC>Это медленно, дорого и на практике редко когда полезно.
Редко, но метко, как говорится.
vsb>>9. Возможность организовать дубликат на удалённом хосте, т.е. все изменения идут по сети на удалённый хост и применяются там, таким образом там будет идентичная ФС.
CC>Зачем это в FS?
Потому, что только ФС может сделать это эффективно, она знает точно всё, что происходит с файлами. Например я открыл 20-гигабайтный файл, сделал seek на середину и поменял 10 байтов. По факту изменился 1 блок (4096 Б), который достаточно переслать по сети для синхронизации. Если же пользоваться какими-то внешними утилитами, им как минимум придётся по всему файлу считать какие-то чексуммы и тд, гораздо сложней реализация и гораздо медленней будет работать.