Ext4 такая ext4

от задачи зависит. если файл 1 мегабайт и ты изменяешь его раз в месяц это одно, а если он 10 гигов и изменяется раз в секунду это другое...

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

Или если не хочется восстанавливать десятки ТБ данных из бэкапа потому что быстро эту операцию не сделать, а время - деньги.

несколько десятков тб, если это порноархив не хранят тщательно, его можно перекачать.

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

у меня на этот случай bacula работает, восставновление упирается только в сеть, (а она гигабитная по офису, между серверами же 10ка), поэтому восстановление проходит очень быстро.

А почему никто не говорит что в ext4 журналируются только метаданные ? И ситуация с обнулением типична при подобном подходе ? Btrfs еще сырой остается только ReiserFS ?

а в райзере уже простые данные журналирует? Кстати, ext4 тоже так умеет, только это никому не нужно. Включи, попробуй...

Вам рассказать, СКОЛЬКО это будет стоить?

расскажи.

у меня на этот случай bacula работает, восставновление упирается только в сеть, (а она гигабитная по офису, между серверами же 10ка), поэтому восстановление проходит очень быстро.

давай посчитаем, 10ТБ / 100Мб/с ~= 30часов. И это в идеальном случае, с мелкими файлами ой как всё медленнее будет, даже на iscsi винтах.

Ты правда думаешь, что придется разом восстанавливать 10тб? :)


К тому же есть еще инкрементальные бекапы

Фишка в том, что операция №3 выполняется ДО операции №2

До «завершения операции», а то каузальность совсем нарушается.

3. одновременно преименовываем старый file в file~, и новый файл в file.

А как это одновременно, есть такой системный вызов?

Если в файл ещё просходит запись, почему операция по переименовыванию файла тоже не откладывается / не блокируется до завершения предыдущей? Есть смысл в использовании перименованного файла, если его содержимое в процессе изменения?

До «завершения операции», а то каузальность совсем нарушается.

если я выше писал, что эта операция может быть длительная, то ИМХО очевидно, что до завершения...

А как это одновременно, есть такой системный вызов?

почему - нет? каталог пишется целиком на диск.

Если в файл ещё просходит запись, почему операция по переименовыванию файла тоже не откладывается / не блокируется до завершения предыдущей?

не знаю. Если-бы она блокировалась, то файл бы не обнулялся.

Есть смысл в использовании перименованного файла, если его содержимое в процессе изменения?

тоже не знаю. Почему - нет?

А из коробки журнал включается ? Или опять руками через опции монтирования ?

Кому надёжность, кому производительность...

Месье работает на интел атоме из принципа ? Попробуйте амд раскаченный до 4ГГц хотя бы. http://cs403825.userapi.com/v403825982/1f6a/XKZwwIKOlJI.jpg Не думаю что на ноуте можно реально ощутить разницу от опций монтирования.

Месье работает на интел атоме из принципа ? Попробуйте амд раскаченный до 4ГГц хотя бы.

да хоть до 8и. Тут не в CPU беда. Если у тебя есть журнал с данными, то

1. тебе придётся постоянно дёргать головки от данных до журнала, т.е. на полдиска. Либо ставить отдельный HDD для журнала. Либо SSD может помочь, если ты готов, что на него *постоянно* будет что-то писаться, и прослужит этот недешёвый девайс очень не долго.

2. от отложенной записи тебе придётся отказаться, и придётся ждать, пока завершится *любая* запись на диск. Особенно обидно, если ты создаёшь временный файл, что-то туда пишешь, а потом уничтожаешь. Сейчас это *вообще* не приводит к активности HDD, файл до туда просто не успевает доехать. Но по твоей логике - придётся ждать... Пока в файл запишем, пока в журнал, пока поменяем, пока удалим... И всё это для того, что-бы *ничего* не сделать. Ибо на диске в итоге ничего не изменилось, как не было файла, так его и нет. Особенно это тебя «порадует», если это SSD.

Я давно говорил, что лучше NTFS пока не придумано ФС.

А из коробки журнал включается ?

к счастью, из коробки журнал данных НЕ включается. Маинтейнеры ещё не настолько упоролись. Но всё в твоих руках: vim /etc/mke2fs.conf секция [defaults]. Это для EXT. Для остальных не ведаю, погугли.

Я давно говорил, что лучше NTFS пока не придумано ФС.

я лет 20 назад тоже так говорил. А тебе уже пора разморозиться.

Я давно говорил, что лучше NTFS пока не придумано ФС.

кстати, NTFS при отключении частенько рушит не только данные, но и даже структуру. Напрочь. Потому, кроме как для порнографии, эту ФС лучше вообще не юзать. Для CP - удобно, если оно рухнет, никакой эксперт не докажет, что там было CP, а не случайная мешанина мусора. Такой встроенный shred.

да хоть до 8и. Тут не в CPU беда. Если у тебя есть журнал с данными, то

Это милисекунды, вы их не почуствуете.

1. тебе придётся постоянно дёргать головки от данных до журнала, т.е. на >полдиска. Либо ставить отдельный HDD для журнала. Либо SSD может помочь, >если ты готов, что на него *постоянно* будет что-то писаться, и прослужит этот >недешёвый девайс очень не долго.

Диски для того чтоб на них писать. Берите интел по статистике он надежнее. Кроме того если диск выйдет из строя то его поменяют по гарантии.

За те «20 лет» ни разу не рухнуло так, чтобы все обрушить. А вот с ext3, ext4, reiserFS такое частенько у меня бывало. Говорю не как эксперт по ФС (если тут такие имеются) а как рядовой пользователь. И мне как бы становится посрать на лицензионную чистоту и внутреннюю красоту, когда данные летят.

п.с. А порнуху (как и всякие киношки) лучше уже на XFS хранить, она специально для больших файлов заточена (надеюсь, вы качаете порнуху уже в BD-RIP, дабы гениталии стали еще более чёткими).

Я давно говорил, что лучше NTFS пока не придумано ФС.

На самом деле она не сильно отличается от всех остальных (если не щитать ZFS и BTRFS с их COW) просто ntfs оптимизирована на запись , резервирует место под MFT и пишет в ближайшие свободные, и пофиг как потом читать ... для исправления ситуации с чтением есть дефраг :-))

Ну, и почему не сделать такое «простое» в какой-нибудь дефолтной ФС под Линукс? Я еще раз говорю, как пользователю мне все равно, что там — ext3 или ext4 с еще более крутым журналированием — мне нужно чтобы данные не слетали, если внезапно сядет батарейка на ноуте, а система питания не обрубит его до штатно.

к счастью, из коробки журнал данных НЕ включается. Маинтейнеры ещё не >настолько упоролись. Но всё в твоих руках: vim /etc/mke2fs.conf секция [defaults]. >Это для EXT. Для остальных не ведаю, погугли.

https://github.com/nagual2/Test/blob/master/test_fs_memdisk_ubuntu.sh Starting newfs ext4 ... Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize И это с опциями по умолчанию. Дистр убунты свежий Ubuntu Server 12.04.1 LTS 64 bit

в /etc/mke2fs.conf видим <------>ext4 = { <------><------>features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize <------><------>auto_64-bit_support = 1 <------><------>inode_size = 256 } Похоже они таки упоролись ...

надеюсь, вы качаете порнуху уже в BD-RIP, дабы гениталии стали еще более чёткими

Скиньте ссылок :-))

Ну, и почему не сделать такое «простое» в какой-нибудь дефолтной ФС под Линукс? >Я еще раз говорю, как пользователю мне все равно, что там — ext3 или ext4 с еще >более крутым журналированием — мне нужно чтобы данные не слетали, если >внезапно сядет батарейка на ноуте, а система питания не обрубит его до штатно.

А вы опции монтирования не меняйте с особым садизмом :-))

Ты правда думаешь, что придется разом восстанавливать 10тб? :)

тут мы подходим к интересному вопросу как понять какие данные задел сбой.

Ну и обсуждение ушло в сторону. Изначально я и говорил что надёжность файлухи очень важна чтобы не пришлось восстанавливать всё ибо время восстановления с нуля может быть очень большим. Помню 7млн файлов по гигабиту восстанавливал... По объёму пара тб, упёрлось всё отнють не в канал.

Это милисекунды, вы их не почуствуете.

да, конечно. по несколько сотен миллисикунд на *каждую* запись? Упоролся что-ли? Это систему месяц загружать. А до иксов я не доживу.

Диски для того чтоб на них писать.

если ты самый умный, то сам так и делай. Не нужно пороть чушь.

Ребят, вы зря спорите. данные бывают разные. Соотв. на одни пофиг, а на другие делается fsync(). Скорость, конечно, разная. Это же всё обсуждалось.

Есть принудительный сброс кэша, есть журналы, есть барьеры... Использовать это или нет решается юзером и приложением.

да, конечно. по несколько сотен миллисикунд на *каждую* запись? Упоролся что->ли? Это систему месяц загружать. А до иксов я не доживу.

Даже geom журнал не загружает систему на целый месяц :-))

За те «20 лет» ни разу не рухнуло так, чтобы все обрушить.

честно говоря уже тошнит от ваших маздайных сказок. Пойми: ты - не показатель. У тебя не рухнуло, а у меня вот - рухнуло. И что? Я как-то неправильно выдрал вилку из розетки? Давай не уподобляйся, а то мне тоже тут один рассказывал пару лет назад про Windows7 с десятилетним аптаймом...

А вот с ext3, ext4, reiserFS такое частенько у меня бывало.

Очевидно потому, что ты наивно уверовал в магию райзера, и в Святый Нерушимый Журнал. А потом осознал, что тебя, наивного, опять развели. И нет никакой магии... Да. Магии не существует. в ФС во всяком случае. Такие дела...

Говорю не как эксперт по ФС (если тут такие имеются) а как рядовой пользователь. И мне как бы становится посрать на лицензионную чистоту и внутреннюю красоту, когда данные летят.

я тоже не Эксперт. Но таки пришлось мне неоднократно восстанавливать данные на диске. Почти всегда NTFS, иногда FAT. Понятно, что *это* не говорит о том, что они плохие, просто на 146% компов венда, а она ничего кроме NTFS не умеет. Однако, как рушится NTFS я знаю не понаслышке. Также я часто встречался со сбоями в EXT3, обычно после этих сбоев всё нормально. Структура ФС более-менее сохраняется. Даже если сам носитель полумёртвый (и такое было), с него можно стянуть образ, который потом разворачивается на нормальном диске. Да, потери бывают, но обычно не критичные. Часто всё потерянное вытягивается из lost+found, а иногда даже этого не нужно, потому-что убиваются обычно только открытые на запись файлы, а их почти всегда можно записать ещё раз.

Ну и вообще, ИМХО вероятность потери данных из-за того, что их не смогла восстановить fsck.ext4 намного _ниже_, чем вероятность того, что HDD тупо возьмёт и сдохнет. Просто так. Такого говна у меня уже целый шкаф, выкинуть надо, а мне лень. Такие дела.

И да, не путайте мну с другим анонимусом - на лицензию мне плевать. Я не воен Света и НЕ RMS.

п.с. А порнуху (как и всякие киношки) лучше уже на XFS хранить, она специально для больших файлов заточена (надеюсь, вы качаете порнуху уже в BD-RIP, дабы гениталии стали еще более чёткими).

ИМХО EXT4 годна и готова для БОЛЬШИХ файлов. У EXT3 были с этим проблемы (fsck.ext3 была очень тормозной), но в EXT4 всё нормально. Т.ч. XFS не нужна. ИМХО.

Надо было NTFS использовать!

просто ntfs оптимизирована на запись

ты просто бредишь. Только идиот может оптимизировать ФС на запись, зная, что подавляющая часть операций - чтение. На самом деле, как раз писать твоя NTFS НЕ умеет. Разве ты не знаешь, что пишет она так хреново, что потом это хрен прочитаешь за разумное время? Разве не знаешь, что её фрагментация настолько сильно замедляет чтение, что пришлось даже придумать дефрагментатор, и заставить юзера регулярно его запускать? EXT тоже фрагментирует файлы, вот только это никому не мешает.

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

ага. классненькая такая «оптимизация» - накидаем данные юзера на диск, как он говно в унитаз кидает... А ничего, что потом юзеру с этими данными работать? Автоматический говносортировщик сделаем? Хороший ход.

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

включи обратно создание *~ файлов, которое по дефолту включено, а ты его выключил. Думаешь эти файлы просто так придумали? Замена ФС тебе НЕ поможет. Такую ФС ещё не придумали.

Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize И это с опциями по умолчанию. Дистр убунты свежий Ubuntu Server 12.04.1 LTS 64 bit

и где ты тут видишь журналирование данных? я в своём мане вообще не нашёл упоминаний о таком режиме. У меня только метаданные журналируются (как и у тебя), что позволяет сохранять *структуру* ФС. Но никак не данные. ИЧСХ, какой файл в каком каталоге - это НЕ структура, это данные в каталоге. Любой каталог может ВНЕЗАПНО обнулиться, и с этим ничего не поделать. Журнал тут не поможет, ибо обнуление данных внутри каталога - не проблема структуры. Файл будет считаться потерянным, и fsck отправит его в /lost+found.

Похоже они таки упоролись ...

к счастью это не так.

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

зато моя программа знает о своих задачах и исходя из знания о атомарности fdatasync в пределах сектора может гарантировать целостность своих данных

зато моя программа знает о своих задачах и исходя из знания о атомарности fdatasync в пределах сектора может гарантировать целостность своих данных

а моя sed -i*~ без всяких атомарностей и без всяких sync и так гарантированно сохраняет данные, потому-что их не уничтожает.

Только идиот может оптимизировать ФС на запись, зная, что подавляющая часть операций - чтение.

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

EXT тоже фрагментирует файлы, вот только это никому не мешает.

этот миф я резвеивал ещё лет десять назад. Ты просто не видел как работают старые бэкап-сервера.

Да что там, достаточно скачивать просто два больших одновременно чтобы получить ппц фрагментацию. ПОэтому man fallocate и придумали.

фу таким быть.

ты несколько не в теме: вот например EXT при создании новых файлов резервирует несколько соседних блоков (ЕМНИП 8), в которых не создаются новые файлы. Потому, когда новый файл начинает расти, он растёт одним куском, внутри этих зарезервированных блоков. В NTFS нет такой оптимизации, насколько я знаю (что там есть на самом деле - точно неведомо никому). Это приводит к тому, что если высыпать на диск 100500 файлов в 100 байт, то на EXT они будут занимать значительную площадь блина, и головкам придётся дёргаться по всей поверхности. А вот если высыпать эти 100500 файлов на NTFS, то они лягут компактным, монолитным куском. Потому многие считают, что EXT не годна для мелких файлов. Это не так, ибо IRL такое практически не встречается, в отличие от тестов. С другой стороны, даже небольшие файлы в NTFS часто сильно фрагментированы, что сильно замедляет как чтение, так и запись ЧСХ.

Самое обидное, что хаять NTFS - плохой тон, мало кто задумывался об 100500 файлов 30 лет назад, когда эта NTFS собственно и проектировалась. Да и проблем тогда с этим не было. Проблемы появились значительно позже. В EXT2,3,4 их исправляют, а в NTFS они by design. И не лечится.

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

оптимизация - вопрос сложный. Например: у тебя есть рюкзак, как БЫСТРЕЕ всего туда сложить вещи? Очевидно - покидать как получится быстрее всего. Минусы тоже очевидны - доставать нужное долго, и влезет мало. Вот под «оптимизацией записи» я и понимал подход NTFS - покидать как получится. Да, это быстро. Но... Вы сами понимаете.

И кто сказал что нельзя чтение и запись оптимизировать одновременно?

можно. Для этого нужно делать новые ФС, учитывая ошибки старых. Вот сейчас активно пилят btrfs, думаю, получится годная новая FS, лучше EXT, которую видимо скоро будет пора закапывать. Ну а юзать УГ мамонта NTFS могут только законченные некрофилы.

вот например EXT при создании новых файлов резервирует несколько соседних блоков (ЕМНИП 8), в которых не создаются новые файлы. Потому, когда новый файл начинает расти, он растёт одним куском, внутри этих зарезервированных блоков. В NTFS нет такой оптимизации

всего 8 блоков, это ниочём для большого файла. Так что я таки в теме.

этот миф я резвеивал ещё лет десять назад. Ты просто не видел как работают старые бэкап-сервера.

видел. и что? да, время от времени надо всё равно всё «дефрагментировать». Высыпать всё, и засыпать обратно.

Да что там, достаточно скачивать просто два больших одновременно чтобы получить ппц фрагментацию. ПОэтому man fallocate и придумали.

ппц оно будет только с т.з. каких-то наколенных скриптов. Юзать файлы тебе это не помешает. Проверено.

ПОэтому man fallocate и придумали.

не по этому. Всё дело в том, что ФС не в курсе, какой размер будет у файла. fallocate это один из способов подсказать ФС размер файла. Конечно, если это возможно, то его нужно использовать.

ппц оно будет только с т.з. каких-то наколенных скриптов. Юзать файлы тебе это не помешает. Проверено.

при чём тут скрипты и наколеночность? Для тру-ынтырпрайз скриптов какие-то другие проблемы? Скорость хромать будет при чтении. А так же при записи если свободное место сильно фрагментировано.

Высыпать всё, и засыпать обратно.

это долго и нужен второй носитель такого же объёма. Спасибо, не надо.

при чём тут скрипты и наколеночность? Для тру-ынтырпрайз скриптов какие-то другие проблемы?

есть труЫнтерпрайзные дефрагментаторы для EXT? Кто-нить в Ынтерпрайзе их юзает? Лично я встречал только наколенные поделки.

Скорость хромать будет при чтении. А так же при записи если свободное место сильно фрагментировано.

в теории - да. На практике незаметно.

это долго и нужен второй носитель такого же объёма. Спасибо, не надо.

диски - расходный материал. Их по любому менять надо. Лично я например не очень понимаю, зачем нужен в Ынтерпрайзе сервер, у которого HDD 2002го года выпуска? Хотя допускаю, что такое есть. А это хорошо?

Похоже проблема с ext4 есть: http://actika.livejournal.com/619.html Обновил тесты.

в теории - да. На практике незаметно.

На практике нормальные люди когда диск заполняется выше 70% ищут новый диск :-))

Похоже проблема с ext4 есть: http://actika.livejournal.com/619.html Обновил тесты.

всё такое цветастое... я ничего не понял...

На практике нормальные люди когда диск заполняется выше 70% ищут новый диск :-))

да. Но на маздае всё жутко тупило и при 70%. В Linux я этого не наблюдаю. Это тоже не баг а фича, как с памятью? В венде нет ООМ киллера - не нужен. До того момента, когда ООМ приходит в линуксе, в венде просто не дожить, ибо тооормоооозиииииииии~

С объёмом HDD та же история?

в теории - да. На практике незаметно.

на порядок тормознее работает. Проверь.

диски - расходный материал. Их по любому менять надо.

речь не об этом. чтобы перезалить инфу надо иметь где-то свободное место аналогичного объёма.

До того момента, когда ООМ приходит в линуксе, в венде просто не дожить

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

Вообще не понимаю как вы с такими проблемами встречаетесь.
Вообще не парюсь насчет ФС, юзаю везде ext3 - все прекрасно работает, ничего случайно не удаляется, не крашится.
Да, если бы пришлось админить сервак - там бы надо повозиться с выбором и настройкой ФС. Но на домашней/рабочей машине - зачем?
Вы там какое-то нагрузочное тестирование что-ли проводите? Или какой-то узкий юзкейс?

на порядок тормознее работает. Проверь.

я проверял. IRL фрагментация есть, но влияние её я не заметил. Ну может на 20% лучше/хуже. Но никак не на порядок.

речь не об этом. чтобы перезалить инфу надо иметь где-то свободное место аналогичного объёма.

у меня такое место _всегда_ есть, ибо я делаю бекапы. Так то.

IRL фрагментация есть, но влияние её я не заметил. Ну может на 20% лучше/хуже. Но никак не на порядок.

запусти любой бенчмарк и посмотри random read speed.

оно не так работает. оно включается не тогда когда памяти нет, а когда ядро хочет больше памяти.

ядро-то тут причём? приложение хочет, а нету.

А так тормозить и свопится будет и линух. Кроме того у меня как-то сеть упала ири нехватки памяти (драйвер e1000), хотя казалось бы должен был oom включиться.

вот оом и включился, и кильнул сеть. В логе об этом должна быть запись. А ты что хотел? Что-бы лишний гиг мозгов материализовался?