MA>http://ru.wikipedia.org/wiki/Сравнение файловых систем MA>снапшоты присутствуют и в NTFS
Это хорошо. Расскажи мне, пожалуйста, как мне сделать динамический снапшот? С точностью до копи-пейст, не терпится попробовать.
MA>а вот длина имени файла в ZFS написано — не может превышать 256 байт, вот это уже странно
Чего странного, нормальное ограничение. MA>кажется в NTFS и то 1024 байта, правда стандартный проводник Win7 режет имена в отличии от XP...
Нет, то же самое — 255 символов.
MA>собственно вопрос про символические ссылки актуальнее снапшотов — скажите, что будет если между томами начать копировать символические ссылки более 1024 байт общей длинны пути до указываемого файла — возникнет исключение или просто накроется всё действие, как в win7?
В ZFS общая длина пути ничем не ограничена.
Здравствуйте, Vamp, Вы писали:
B>>Use-case для простого юзера? V>Обновление приложения. Обновляешь его в снапшот — и вуля. Если не работает, откатываешь снапшот.
Это всё автоматом будет делаться? А то у меня есть сомнения, что пользователь в состоянии сам провернуть такие манипуляции.
Здравствуйте, mister-AK, Вы писали:
MA>судя по этой ссылке: MA>http://ru.wikipedia.org/wiki/Сравнение файловых систем MA>снапшоты присутствуют и в NTFS
Нет их там и близко....
Как нет и:
1) Динамического RAID'а на уровне отдельных каталогов. Скажем, можно пометить, что /home — это RAID-1 (зеркалируется) для надёжности, а вот /usr и /var — это RAID-0 (страйпинг) для скорости.
2) CoW (Copy-on-Write) на уровне файлов и всей FS (можно заглядывать в историю).
3) Онлайновая дефрагментация.
4) Дедубликация данных.
...
Здравствуйте, Vamp, Вы писали:
B>>Это всё автоматом будет делаться? А то у меня есть сомнения, что пользователь в состоянии сам провернуть такие манипуляции. V>В Солярке — автоматом.
B>Простой юзер на Соляре
Во-первых, не вижу ничего необычного. Простому юзеру работать на Солярке ничего не помешает.
Во-вторых, что значит "простой"?
В третьих, это вообще офтопик — мы обсуждаем файловую систему и ее возможности, и я привел Солярку просто как пример.
Приветствую, mister-AK, вы писали:
AK> интересуют например корректная работа аналога junction и вообще, какие нововведения для "простого юзера"?
Поддерживаемый объем. Правда винтов столько в мире нет, чтобы такого объема массив собрать, но это мелочи, правда? )
S>Похоже ты действительно зеленеешь. Явные показатель зелености — цепляться за мелочи, риторические вопросы, да и вообще обилие вопросов в одном посте (с целью в дальнейшем выбрать наиболее вкусную "ветку", этакий огонь по площадям.). S>Я тебе уже сказал — разжевывать не буду. Расти зубы сам. Тем более я и так все объяснил.
Я, кстати, из твоих объяснений так ничего не понял. И не только я, судя по всему.
Мы имеем стабильную и нестабильную ветку.
В нестабильной ветке может быть софт с багами, причем существенными (судя по твоим же словам). Что мешает нестабильному BTRFS'у появиться в нестабильной ветке?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, mister-AK, Вы писали:
MA>>судя по этой ссылке: MA>>http://ru.wikipedia.org/wiki/Сравнение файловых систем MA>>снапшоты присутствуют и в NTFS C>Нет их там и близко....
C>Как нет и: C>1) Динамического RAID'а на уровне отдельных каталогов. Скажем, можно пометить, что /home — это RAID-1 (зеркалируется) для надёжности, а вот /usr и /var — это RAID-0 (страйпинг) для скорости.
возможно это есть у сторонних поставщиков. вобще RAID он хорош только на кластерном уровне, а не на более высоком уровне файловоц системы. C>2) CoW (Copy-on-Write) на уровне файлов и всей FS (можно заглядывать в историю).
насчет истории не в курсе, а вот файлы вроде NTFS перемещает только с тома на том, а внутри тома — только ссылки в файловой таблице C>3) Онлайновая дефрагментация.
вроде по уму NTFS оперирует только с таблицей ссылок на файлы, а не фрагменты перемещает как уже сказал, так что фрагментация на лету не самое важное, у меняф покрайней мере не было за последние 10 лет проблем с тормозами, даже в папках где набито по 100 тыс. файлов
C>4) Дедубликация данных.
есть такая утиилита, http://malich.ru/duplicate_searcher.aspx
лучше было бы её встраивать в ОС, но не всегда нужна обязательная дедубликация данных, иногда она даже вредна, например вы себе представляете что будет, если в винде сделать жесткие ссылки на DLL, а не раскидывать их по папкам производителей... если конечно по науке типа общий репозиторий, то да, но винда к этому неприспособлена C>...
Здравствуйте, Vamp, Вы писали:
MA>>http://ru.wikipedia.org/wiki/Сравнение файловых систем MA>>снапшоты присутствуют и в NTFS V>Это хорошо. Расскажи мне, пожалуйста, как мне сделать динамический снапшот? С точностью до копи-пейст, не терпится попробовать.
MA>>а вот длина имени файла в ZFS написано — не может превышать 256 байт, вот это уже странно V>Чего странного, нормальное ограничение. MA>>кажется в NTFS и то 1024 байта, правда стандартный проводник Win7 режет имена в отличии от XP... V>Нет, то же самое — 255 символов.
совершенно ненормальное — ввиду того что единого стандарта на хранение атрибутов файла нет — приходится иногда всё это хранить в строке имени, про передаче между разными ОС. Посмотрите например как именуют книги на книгохранилищах, чтобы эмпирически убедиться что в 256 иногда не укладывается автор/название/год издания монографии/диссертации если туда присобачить вторичные атрибуты — издательство/издание/язык оригинала и перевода/ dpi/ число стр. или вы это предлагаете отдельным потоком к файлу крепить, чтобы другие файловые системы эту инфу теряли?:
MA>>собственно вопрос про символические ссылки актуальнее снапшотов — скажите, что будет если между томами начать копировать символические ссылки более 1024 байт общей длинны пути до указываемого файла — возникнет исключение или просто накроется всё действие, как в win7?
не вижу ответа на животрепещущий вопрос
V>В ZFS общая длина пути ничем не ограничена.
а может проверить? в NTFS при длине пути более 10тыс. символов например может загнуться проводник
MA>совершенно ненормальное — ввиду того что единого стандарта на хранение атрибутов файла нет — приходится иногда всё это хранить в строке имени, про передаче между разными ОС. Посмотрите например как именуют книги на книгохранилищах, чтобы эмпирически убедиться что в 256 иногда не укладывается автор/название/год издания монографии/диссертации если туда присобачить вторичные атрибуты — издательство/издание/язык оригинала и перевода/ dpi/ число стр. или вы это предлагаете отдельным потоком к файлу крепить, чтобы другие файловые системы эту инфу теряли?:
Я бы предлагал не превращать файловую систему в базу данных.
MA>>>собственно вопрос про символические ссылки актуальнее снапшотов — скажите, что будет если между томами начать копировать символические ссылки более 1024 байт общей длинны пути до указываемого файла — возникнет исключение или просто накроется всё действие, как в win7? MA>не вижу ответа на животрепещущий вопрос
Не понял вопроса. В ZFS нет понятия "том", а копирование символических ссылок вообще не поддерживается в известных мне системах.
MA>а может проверить? в NTFS при длине пути более 10тыс. символов например может загнуться проводник
Не путай, пожалуйста, файловую систему и приложение.
Здравствуйте, Mamut, Вы писали:
M>В нестабильной ветке может быть софт с багами, причем существенными (судя по твоим же словам).
судя по его словам, в нестабильной ветке софт релизный, просто [возможно] криво опакеченный. вот и думай тут о качестве разжёвывания, если мы по-разному поняли
Здравствуйте, mister-AK, Вы писали:
C>>Как нет и: C>>1) Динамического RAID'а на уровне отдельных каталогов. Скажем, можно пометить, что /home — это RAID-1 (зеркалируется) для надёжности, а вот /usr и /var — это RAID-0 (страйпинг) для скорости. MA>возможно это есть у сторонних поставщиков. вобще RAID он хорош только на кластерном уровне, а не на более высоком уровне файловоц системы.
Нет у сторонних поставщиков этого. А у RAID на уровне блочных устройств намного менее гибкий, чем в ZFS/btrfs.
C>>2) CoW (Copy-on-Write) на уровне файлов и всей FS (можно заглядывать в историю). MA>насчет истории не в курсе, а вот файлы вроде NTFS перемещает только с тома на том, а внутри тома — только ссылки в файловой таблице
Я не про перемещение говорю. В btrfs/zfs при копировании файлов реально данные не копируются (т.е. сложность O(1) ). И только при записи в копию под изменённые страницы будет распределено место.
C>>3) Онлайновая дефрагментация. MA>вроде по уму NTFS оперирует только с таблицей ссылок на файлы, а не фрагменты перемещает как уже сказал, так что фрагментация на лету не самое важное, у меняф покрайней мере не было за последние 10 лет проблем с тормозами, даже в папках где набито по 100 тыс. файлов
Нет. NTFS фрагментируется мгновенно. Фрагментация относится не к метаданным, а к самим данным.
C>>4) Дедубликация данных. MA>есть такая утиилита, http://malich.ru/duplicate_searcher.aspx
Не то. В btrfs это происходит на уровне FS. Т.е. два разных файла с одинаковой страницей будут ссылаться на одну и ту же страницу на диске. А дальше — CoW. Причём необязательно, чтобы файлы целиком были одинаковы.
В NTFS это невозможно.
MA>лучше было бы её встраивать в ОС, но не всегда нужна обязательная дедубликация данных, иногда она даже вредна, например вы себе представляете что будет, если в винде сделать жесткие ссылки на DLL, а не раскидывать их по папкам производителей... если конечно по науке типа общий репозиторий, то да, но винда к этому неприспособлена
Ничего не будет. Дедубликация работает полностью прозрачно.
