Группа исследователей из Техасского университета в Остине разработала (https://www.usenix.org/conference/atc18/presentation/hu) новую файловую систему TxFS, предоставляющую встроенную поддержку транзакций, удовлетворяющих требованиям ACID (атомарность, согласованность, изолированность, надежность). Код ФС доступен (https://github.com/ut-osa/txfs) только в виде модифицированный исходных текстов ядра Linux 3.18, патчей для других версий пока нет.
TxFS даёт возможность выполнить атомарное применение сразу группы операций над файлами. Например, в рамках изолированной транзации можно выполнить несколько операций записи в разные файлы, а затем атомарно разом применить накопленные изменения, используя синтаксис begin/commit, похожий на транзакции в СУБД. Или можно откатить все внесённые в разные файлы изменения в случае, если в процессе обработки данных были выявлены какие-то проблемы.ret = fs_tx_begin();
fd1 = open("file1.txt", O_RDWR | O_APPEND, 0644);
fd2 = open("file2.txt", O_RDWR | O_APPEND, 0644);
write(fd1, "foo\n", 4);
write(fd2, "bar\n", 4);
ret = fs_tx_commit(); // или fs_tx_abort() для отмены транзакции
ФС TxFS построена поверх штатной инфраструктуры журналирования jbd2 (Journaling block device) и файловой системы Ext4. Производительность системы сопоставима с производительностью обычной файловой системы Ext4. Реализация достаточно компактная и включает в себя всего 5200 строк кода, из которых 1300 составляет внутренний код (разрешение конфликтов, реализация системных вызовов), 1600 - изменения в VFS, 900 - изменения кода журналирования JBD2, 1200 - изменения в ext4 и 200 - изменения кода управления памятью. Помимо кода для расширения ext4 и jbd2 все остальные компоненты универсальны и в будущем могут быть использованы для адаптации TxFS для других ФС, таких как ZFS.
API для управления транзакциями реализован через надстройку над тремя новыми системными вызовами, обеспечивающими открытие, фиксацию и отмену транзакций. В настоящее время подготовлены порты SQLite и Git, использующие TxFS для обеспечения гарантированной устойчивости к сбоям. Благодаря упрощению логики обеспечения атомарности в приложениях и сокращению числа сбросов буферов через fsync(), порт SQLite на базе TxFS показал в тесте TPC-C увеличение производительности в 1.6 раза. Пропускная способность приложения Android Mail при использовании порта SQLite возросла в 2.3 раза. Порт Git продемонстрировал существенное увеличение надёжности и способность предотвращать повреждения данных и нарушения целостности при сбоях во время выполнения операций с репозиторем.URL: https://www.usenix.org/conference/atc18/presentation/hu
Новость: https://www.opennet.me/opennews/art.shtml?num=48981
Фига они быстрые! Я только месяц назад начал размышлять, как по настоящему транзакционная ФС должна выглядеть, а эти уже реализовали. Молодцы!
Год назад:https://www.sqlite.org/fasterthanfs.html
> SQLite reads and writes small blobs (for example, thumbnail images)
> approx. 35% faster than the same blobs can be read from or written
> to individual files on disk using fread() or fwrite().
> Furthermore, a single SQLite database holding
> 10-kilobyte blobs uses about 20% less disk space than
> storing the blobs in individual files.
> The measurements in this article were made during the week of 2017-06-05
> using a version of SQLite in between 3.19.2 and 3.20.0. You may expect
> future versions of SQLite to perform even better.
...целый месяц!
Этим программист от пользователя и отличатся, что второй только размышляем, мечтает и хотелки высказывает.
> Я только месяц назад начал размышлятьКа только каникулы начались, так сразу и начал "размышлять"?
У меня круче было. Полночи изобретал солнечный коллектор на вакуумных трубках. С утра еду в магазин стройматериалов, а китайцы уже сделали, все что я за ночь придумал, и к нам в магазин завезли. )))))
CICS
Если базы данных начнут эти расширения поддерживать - то взлетит. Но только в этом случае.
Базам данных-то это зачем? У них транзакции свои, нормальные, из коробки.
С одной стороны конечно это так, но с другой:
To demonstrate the power and ease of use of TxFS transactions, we modify SQLite and Git to incorporate TxFS transactions. We show that when using TxFS transactions, SQLite performance on the TPC-C benchmark improves by 1.6x
Эффективно они вроде как подменили журнал наката SQLite журналом ФС. Возможно это даёт какие-то преимущества по скорости. Мне вот что только непонятно: БД оперирует записями, а TxFS - объектами ядра, т.е. страницами. Одна страница может содержать много записей. Вот что происходит в TxFS, если мы интенсивно апдейтим/добавляем/читаем записи из множества транзакций, обращаясь к одной и той же странице? Инсерты будут создавать разреженные страницы, содержащие одну или несколько записей, созданные одной транзакцией? Конфликты при доступе на чтение и апдейт к уже закоммиченным данным? Это же вполне реальный юзкейс: приходят данные и как-то обрабатываются, при этом новые данные обычно ложатся рядом и при этом они наиболее востребованы другими приложениями.
Базы точно так же оперируют страницами с данными, записями было б слишком дорого.
> Базы точно так же оперируют страницами с данными, записями было б слишком дорогоВ БД ты спокойно можешь апдейтить разные записи, сидящие в одном блоке, из разных транзакций. ФС же ничего не знает про твои структуры данных.
Зависит от БД.
В sqlite (стоковом) одновременно может быть только один писатель, т.е. ситуации "ты можешь спокойно апдейтить разные записи из разных транзакций" в принципе нет.
И в классическом режиме (с undo) писатель блокирует читателей тоже, копирует страницы в undo, а меняет их прям на месте.
Этому режиму транзакционная фс очень поможети вместо того, чтобы выгонять читателей и использовать собственный undo, sqlite может использовать транзакции файловой системы.
> И в классическом режиме (с undo) писатель блокирует читателей тоже, копирует страницы в undo, а меняет их прям на месте.Не совсем так, в классическом "Read committed", в худшем случае "пишущая транзакция блокирует изменяемые данные для читающих транзакций" [1], в лучшем - вообще не блокирует. Но, что важно, эти самые "изменяемые данные" - это конкретные строки, которые изменил писатель. А не какие-то единицы хранения данных
> Этому режиму транзакционная фс очень поможети вместо того, чтобы выгонять читателей и использовать собственный undo, sqlite может использовать транзакции файловой системы.
Может на нём и можно реализовать такой эрзац нормальных транзакций, но тогда будет невозможно проектировать приложения без дидлоков, да и работать это всё будет медленнее по сравнению с нормальными СУБД за счёт лишних, не нужных, абортов при изменении разных данных, случайно оказавшихся на одной странице.
> В sqliteПочитал немного про SQLite и до меня дошло, что весь ваш пост был про SQLite.. Заодно дошло, что он там как раз страницами и оперирует с его serializable транзакциями, за ненадобностью блокировок на уровне строк в этом режиме. Так что как минимум сабжевая ФС с ним смотрится естественно. Хотя вот по этому вс равно не понятно что TxFS тут может дать: "вместо того, чтобы выгонять читателей и использовать собственный undo, sqlite может использовать транзакции файловой системы". Чтобы читатели могли сосуществовать с писателями есть WAL - ведь при параллельном чтении может потребоваться множество версий одной и той же страницы. В режиме UNDO - какая разница кто осуществит копирование при записи SQLite или ФС? Ну разве что может за счет того, что происходит в ядре и используются, насколько я понял, аппаратные средства.. Но чтобы ажно в полтора-два раза только из-за этого - сомнительно оно как-то.
> Базы точно так же оперируют страницами с данными, записями было б слишком дорого.Базы оперируют блоками ("страницами с данными") только для чтения/записи на носители (читают/пишут один блок за раз, а не построчно). Но внутри блоков они оперируют записями. Транзакции и блокировки в обычных нормальных реляционных БД имеют своей минимальной единицей манипулирования как раз строку (а не блок). Причем некоторые (опять же, нормальные) БД еще являются и версионными (а не строгими чистыми блокировочными) - одна строка может иметь несколько версий для разных транзакций, в зависимости от уровней изоляции этих транзакций. К примеру (для Оракла и его дефолтного уровня изоляции транзакций) - написАл ты очень сложный запрос связав несколько огромных таблиц. Выполняется этот запрос долго, к примеру, 3 минуты. С момента начала выполнения запроса все данные в таблицах должны быть (для запроса) согласованными, иначе ты получишь неверный результат, ибо в течение этих трех минут еще куча других транзакций может закоммитить кучу изменений (и ты бы в начале выполнения запроса читал старые данные, а во второй-третьей минуте - новые свежие данные). Т.е. читать нужно только данные, зафиксированные на момент начала выполнения оператора SELECT (повторюсь, при дефолтном уровне изоляции транзакций в Оракле). В древних БД-блокировочниках для такой согласованности требовалось бы блокировать целиком все таблицы, входящие в запрос (т.е. 3 минуты никто ничего не пишет в эти таблицы). В БД-версионниках никто ничего не блокирует, SELECT выполняется (в случае необходимости) над старыми версиями строки, если она успела измениться и закоммититься другой транзакцией после начала работы селекта. Правда Оракл немного неполноценный, можно получить исключение snapshot too old, но все же. Делать подобные механизмы БД опираясь на представленный в статье функционал файловой системы - как-то по-детски, от непонимания внутренних алгоритмов работы БД и уровней изоляции транзакций. Вам там ссылку оставили, про эти сами уровни, читайте.
Ну соберите стендик, если интересно. Тут ведь как - новая заявленная функциональность требует и новых методов тестирования - стандартно же ФС - это про файлы и неструктурированные данные, а БД - это про структурированные данные и транзакции.
Прикольно.
> только в виде модифицированный исходных текстов ядра Linux 3.18А что на таком новом непроверенном ядре, надо было на 2.6 делать. Тогда бы точно все поняли что намерения серьёзные, и релиз продуман и подготовлен хорошо.
потому что "stable api is no sense", а людям нужна была работающая реализация, а не бесконечная гонка за механическим зайцем.лучше спросить¸ зачем они для этой задачи выбрали такую безнадежно больную хрень как линукс, и такую устаревшую и неэффективную fs, вместо того, чтобы использовать хотя бы zfs, пусть даже в виде zol, все проще потом портировать.
ну то есть понятно, на самом деле, почему - jbd наше всьо...
Опять у ZFS-фанбоев боли, что кто-то не восхищается этим монструозным корявым поделием.
а что, есть из чего выбирать?
А если еще и хотя бы попытаться сделать не linux-only ?
Хотя да, зачем, "нахрен posix, linux ваш новый стандарт!(c)Леннарт-всегда-прав!"
Выбирай: HAMMER на BSD и BTRFS на Linux. А эта твоя zfs - инородный костыль везде, кроме ее родной, но, к сожалению уже дохлой системы.
> Выбирай: HAMMER на BSD и BTRFS на Linux.то есть две жертвы NIH-синдрома, одну из которых уже второй раз переписали с нуля, а другая все-еще-немножечко-не-совсем-окончательно-готова-для, обе кое-как работающие каждая в своей единственно-верной системе ? спасибо, я уж лучше, как нибудь без этих мертворожденных выкидышей обойдусь.
и ничего, что "дохлая система" - systemV юникс, у которой "родной" является вовсе не zfs?
Это не жертвы синдрома, это жертвы лицензий и юридического крючкотворства. Давайте не будем искажать реальность.
более отвратительно мутной лицензии, чем cddl, придумать сложно (и вполне может еще аукнуться, если в орацле переменится настроение)
ничего - как-то с ней выживает пока zfs. И в линуксе, и во фре, и на маке.а прекрасная (на бумаге) hammer - мертворожденная, хотя лицензия у нее просто прекрасна.
>одну из которых уже второй раз переписали с нуля, а другая все-еще-немножечко-не-совсем-окончательно-готова-для, обе кое-как работающие каждая в своей единственно-верной системеПонятно, очередной форумный куаретик. Всё там работает нормально, если руки прямые конечно.
Нормальные аргументы у тебя есть? Или засчитываем слив?
тогда тебе сразу засчитаем слив, поскольку твой "аргумент" насчет "инородного костыля" высосан из пальца. Нормальная разработка, изначально сделанная настолько переносимой, насколько это вообще было возможно, чтобы в итоге оно работало, а не так и осталось невзлетевшим оверинженерным фуфлом.А сейчас еще и очень-очень сильно испорченная разработчиками zol, которые вместо того чтобы патчить линукс, там где он вполне очевидно устроен череззаднично, подгоняют под его кривизну апстрим, а сановского менеджера с плеткой за спиной не осталось.
так что некоторые детали скорее уж как раз в той "одной системе" (и на самом деле в двух других тоже) - кривые инородные костыли, подпирающие неумение линукса работать с памятью не единственно-верным образом.
А твое "все там работает", это как раз типичный форумный вскукарек админа локалхоста с аптаймом два года.
>HAMMER на BSDНа Dragonfly BSD, ты хотел сказать. Больше нигде её нет.
>BTRFS на Linux
Оно ещё живо?
Что удивительно, ZFS работает в Linux без каких-либо проблем, так что зачем городить костыли?
> Что удивительно, ZFS работает в Linux без каких-либо проблем, так что зачем городить костыли?ну не то чтобы без проблем, но эти проблемы в основном общие, и с иллюмосными тоже.
а вот проблемы btrfs (о мертвых - лучше помолчим) - линуксонли, и даже их отсутствие у одного анонима - "в каком конкретно ядре? Какого дистрибутива?" (причем пользы с этого знания, чаще всего - никакой, мало кто может взять и вот так разом сменить "неправильный" rhel на "правильный" орацле, даже если какая-то болячка при этом раccосется)
>Выбирай: HAMMER на BSD и BTRFS на Linuxчто из этого - пики точеные?
> А что на таком новом непроверенном ядре, надо было на 2.6 делать. Тогда бы точно все поняли что намерения серьёзные, и релиз продуман и подготовлен хорошоВидимо, разработка началась в момент, когда ядро 3.18 было актуальным, и команда решила, что будет удобнее _завершить_ проект на этом ядре, а потом уже портировать оттестированный рабочий код под более новые версии. Это намного эффективнее, чем переписывание еще не готовой программы при каждом обновлении ядра в погоне за версиями.
потому что эта версия используется как основная LTS в куче встраиваемых устройств (естественно, со своими патчами для каждой железки)
Потому-что Линус и КО постоянно воротят VFS включая API, да и в целом в ядре постоянно что-то меняется незначительное.
Android?
В качестве клиента к БД и сопутствующему.
Видимо, под 6-й андроид начинали пилить.
Не взлетит. В их ФС пока одна транзакция произвела запись в страницу данных и ещё не закоммитила транзакцию, никто не сможет прочитать оригинальное содержимое страницы:> 1.When a transaction reads a page, it increments reader count by one. If the page has the write flag set, the transaction aborts.
(с) https://www.usenix.org/system/files/conference/atc18/atc18-h...
Если кто-то постоянно пишет (например в лог), то другие процессы будут абортиться на попытках доступа. А поскольку в реализации нет возможности поиметь несколько разных транзакций на процесс (это выдаётся за преимущество - ведь программисту не придётся возиться с ужасными хендлами), то вместе с попыткой почитать лог, абортнется и всё остальное, что процесс ещё не успел закоммитить.
Вобщем, я бы прикопал эту ФС на какое-то время.
Разве не это ли является примером атомарности?
> Если кто-то постоянно пишет (например в лог), то другие процессы будут абортиться на попытках доступаВо-первых, абортятся не процессы, а транзакции этих процессов, сами процессы продолжат нормально выполняться
Во-вторых, можно спокойно читать лог без транзакций. А кому-то стоит подумать, зачем он использует чтение лога внутри транзакции.
В-втретьих, неплохо бы программисту хоть чуть-чуть понимать как надо работать с транзакциями/блокировками. То есть не держать транзакцию/блокировку дольше необходимости и правильно обрабатывать ошибки при commit. И тогда, о чудо, никакой проблемы не будет.> Вобщем, я бы прикопал эту ФС на какое-то время.
Если что-то не подходит для тебя, то может это лично тебе не надо этим пользоваться.
> Если что-то не подходит для тебя, то может это лично тебе не надо этим пользоваться.Так человек и написал же "*я* бы прикопал" вместо типичного "такое не надо, закопать".
может тогда нужна мультиверсионность?
> может тогда нужна мультиверсионность?Не знаю, что им нужно. Может витаминов.
Они в своей брошюрке утверждают, что "TxFS achieves the isolation level of repeatable reads". Вот только беда, ни один уровень транзакции, в т.ч. и repeatable read не подразумевает того, что тразакция будет абортиться на чтении измененных данных там речь только о том, какие именно данные она прочтёт: https://ru.wikipedia.org/wiki/%D0%A3%D1%...
Кстати да, транзакции без MVCC это ж жеппа
Может, просто не стоит использовать эту ФС на /var, а использовать где-то в более подходящих для неё условиях?
>Во-вторых, можно спокойно читать лог без транзакций. А кому-то стоит подумать, зачем он использует чтение лога внутри транзакции.Лог конечно читать внутри транзакции никчему, но представьте бинарный формат виртуального жёсткого диска. VHD например. Там блоки фиксированного размера, при записи в один менять весь файл не нужно. Допустим 2 разных блока отобразили в память и начали читать и писать в рамках разных транзакций, а потом закоммитили их. Эта штука похоже так не позволяет, значит не нужна.
> VHD например.и зачем тебе транзакции - для vhd? Нет там никаких транзакций и нахрен они ему не нужны.
в общем, беги в школу, опоздаешь. Не в курсе ты, зачем нужны транзакции и где применяются, этого в пятом классе еще не проходили.
Непонятна идея совать это дело в фс, на которой лежит бд, если в бд уже есть свой acid. Про блокировки сказали выше, похоже, что проект является чьим-то курсачом.
> если в бд уже есть свой acidА если нет?
В которой из них нет? Намедни уже даже геи из монгодб про acid вещали.
>> если в бд уже есть свой acid
> А если нет?Если в БД нет ACID, то это значит, что она прекрасно обходилась и обходится (хотя бы в сферической теории) без него.
В смысле, предрекаемое некоторыми комментаторами "Этим БД только не хватало такой ФС. И уж теперь-то вот развернемся-заживем! Ух!" выглядит несколько недостоверно.Ваш Кэп.
Как она себя ведет в случае если есть bad sectors на диске?
Видимо, ровно так же, как повела бы себя та, журналируемая ФС, поверх которой крутится эта транзакционная нахлобучка.
В Qt есть класс QSaveFile (не путать с обычным QFile), сразу про него вспомнил как прочитал новость. Не то же самое, но тоже можно реализовать запись в несколько файлов, а если ошибок не возникло, сделать commit, правда по отдельности для каждого файла. Класс QSaveFile в первую очередь преднозначен чтобы не потерять данные в процессе полной перезаписи всего файла (сохранится прошлая версия файла).
Не задумались о гарантиях-то? Ваши телодвижения без ядра --- это потрясание бубном. И даже за ядром ещё железяки есть...
Так я и написал же, что это не то же самое. Просто вспомнил про интересный класс, который предназначен для вполне конкретной задачи. А гарантии только господь дать может.
Это классно конечно, но в прикладном ПО не должно быть привязки к конкретной файловой системе.
Оптимально - введение флага при открытии файла(типа FLAG_ATOMIC) и ОДНОЙ новой функции типа rollback. Роль "Commit" прекрасно может исполнить тот же flush(..).
> Это классно конечно, но в прикладном ПО не должно быть привязки к конкретной файловой системе."вы прослушали мнение неосилятора configure и #ifdef"
прикладное ПО тебе в общем-то ничего не должно, а если его авторам не лень добавить возможность эффективной работы при наличии дополнительной возможности - кому-то вполне может оказаться полезным.
Помимо sqlite у нас есть еще куча софта со своими "типа-базами-данных", не имеющих выделенного "сервера", и перекладывающих механику реализации локов/атомарных операций на нижележащую fs. Впрочем, настоящим тазам банных тоже может оказаться небесполезно, поскольку хранение оракловой бд на raw partitions давно уже немодно, и в любом случае приходится иметь дело с файловыми системами.
хотя и жаль, конечно, что именно ext4. Будущего у нее, пожалуй, нет.
> хотя и жаль, конечно, что именно ext4. Будущего у нее, пожалуй, нет.Что касается типичного использования, то как и у других развитых ФС на сегодняшний день. Но в отличие от них у неё есть хотя бы настоящее.
> Что касается типичного использования, то как и у других развитых ФС на сегодняшний день.ну вот пользуюсь я той же zfs - атипично, в смысле, не на петабайтных стораджах с терабайтами оперативы, а на вполне себе микровиртуалках или мелких гипервизорах, где нет смысла или не получается по hcl поставить вмварь (или, хуже, хорошо известно что поставить можно, но апгрейду она не подлежит, вендор сдох и новых драйверов не будет) - в целом и работает, если знать заранее где соломку стелить.
полагаю, что, при всей моей нелюбви к поделке оракла, btrfs тоже так же вполне можно пользоваться.
очевидно есть будущее у xfs в редхатовском исполнении. А с ext4 - "жги, тут уже ничего не исправить!"
Интересно, сервера гугля так и сидят на странной конструкции "ext4-nojournal" ?
ext4 на стораджах больше 128Т - это очень грустно.
создавайте / удаляйте файлы в одном каталоге - узнаете много нового.А так - проблем нету.
там гораздо раньше становится грустно.
Собственно, нарваться на побочные эффекты причудливого "экономичненького" решения dirhash может любой админ локалхоста, в этом каталоге не так-то и много надо файлов.а для нелокалхоста там сплошное непаханное поле граблей и в области журнала (не просто так гугль в свое время от него избавлялся) и в области эффективности, и с надежностью местами "works as intended"... А если у тебя не одна ix86 архитектура, то вообще такие чудеса, что диву даешься...
ну ладно, зато вот - "эффективная подкладка под патченную sqlite", неплохое применение. Понятное дело, не о 128 терах речь.
еще б subversion и hg кто-нибудь пропатчил (гиту-то нафиг не надо, на самом деле) - вообще прекрасно было бы.
> Роль "Commit" прекрасно может исполнить тот же flush(..).Думаю, вы не один у нас такой - поэтому объясняю юзкейс.
Допустим у вас есть два файла Ф1 и Ф2, в которых лежат счета клиентов.
Одновременно у вас крутятся несколько процессов, скажем тысяча, которые переводят деньги со счета на счет.Как вы со своим флушей(..) будете избегать ситуаций, при которых у вас случайно будут из баланса исчезать деньги вникуда или, наоборот, появляться из ниоткуда? Даже при крушении системы в середине операции? Да ещё без глобального лока на весь файл, чтобы часть процессов имела шанс отработать параллельно?
А кто в здравом уме, в наше время хранит такие данные в чистой файловой системе?
Так транзакций же в фс доселе не было - вот и не хранят.
Ну а теперича обьективно - каковы плюсы хранения всего этого добра в файлах то?
> Допустим у вас есть два файла Ф1 и Ф2А где в новости указание "транзакция в файловой системе вцелом"?
Разве речь идет не о конкретном одиночном файле?
А про межфайловой транзакции всё равно придется думать конкретному прикладному контролеру!
Извиняюсь, некорректно прочел код.
> ret = fs_tx_begin();
> fd1 = open("file1.txt", O_RDWR | O_APPEND, 0644);
> fd2 = open("file2.txt", O_RDWR | O_APPEND, 0644);
> write(fd1, "foo\n", 4);
> write(fd2, "bar\n", 4);
> ret = fs_tx_commit(); // или fs_tx_abort() для отмены транзакцииГоворим о транзакциях, но результаты fs_tx_begin(), open(), write() не проверяем. Как так?
Кроме того, это всегда было возможно с помошь временной директории или файла и rename(2).
Но не всех ФС. А ещё нельзя перенести все метаданные, например:
https://github.com/geany/geany/issues/1049 (закрыто, известная ошибка но решения нет).Выдержки из https://wiki.geany.org/config/all_you_never_wanted_to_know_a...
[quote]
If use_atomic_file_saving is set, use_gio_file_saving is ignored and Geany will use an atomic file save method.Advantages:
The existing file is not touched until the rename, which happens after the temporary file has successfully been written. So if the write fails, the existing file should not be lost.
Disadvantages:
Because it writes the temporary file as a new file, it will get the permissions and other metadata (eg execute) of a new file, not those of the old file.
Does not work on all file systems since rename or rename over an existing file is not supported on all file systems.
[/quote]
А как у неё с фрагментацией? Так же как у ext4 (почти отсутствует) или в лучших традициях m$? Если есть возможность откатить изменения, то она их складывает где-то рядом. При этом, по идее, фрагментация должна дико расти.
> Так же как у ext4так же
> (почти отсутствует)тебя обманули.
> или в лучших традициях m$?
нет, аналога creat() с prealloc у нас нет и не будет.
в принципе, для многозадачной системы фрагментированность не беда а благо, в определенной степени. А для современных носителей уже и вовсе все равно.
это у ext4 нету франгментации ? вы серьезно?.. давайте посмеемся вместе :)
> это у ext4 нету франгментации ?он не видит - значит, нету ;-) это ms что-то перевозбудилась, понапридумывала ненужных предупреждений и спецтулз, и, вот, в результате - перепугала наивных пингвиняток, хотя у нее эта проблема и выражена гораздо меньше, и пути обхода предусмотрены. А в ext4 оценить фрагментированность - не каждому админу локалхоста дано.
и это он еще про косвенные inodes третьего уровня не в курсе - совершенно отдельная от обычной фрагментации беда.
поддержка двухфазного коммита есть?если нет -- то могут засунуть эту поделку обратно
В их доке сказано, что есть.
тогда могут не засовывать
Не факт.. Лучше это сделать самостоятельно, чем ждать пока это сделает кто-нибудь другой.
Совсем неинтересный стал у вас линукс. Где новости о том, как попрана и опозорена поганая винда? О том как Столлман всем сказал, что так нельзя, а эдак можно? Где новые исошки альт-шигоринса с поддержкой трактора "Богатырь", в конце-концов?
Предлагаю обратное: сходить на фронтам и посмотреть сравнение производительности десяточку с линуксами, и там же найти берут "что будет соскоростью если выполнить все ненужное из нее". Интересненько...
Фроникс.
> Фроникс.Смысл ходить на мороникс и смотреть, если можно сразу из пальца высосать?
Там же одни и те же тесты в одних и тех же ОСях (только с разницей в месяц) могут различаться как небо и земля, но никаких попыток докопаться до причин регресса/прогресса (регрессия, баг в дровах/железе, измененный конфиг) не предпринимается. Тоже самое для всяких чрезмерных девиаций.
А предоставляемых деталей недостаточно для каких-то выводов или, тем более, самостоятельного копания.
Не говоря уже о том, что "тесты" вполне могут запустить и на "похожем" (но не одинаковом) железе.
Простого обывателя причины волнуют слабо. Да и вовсе не должны, на самом деле. Важен лишь результат.
> Простого обывателя причины волнуют слабо. Да и вовсе не должны, на самом деле. Важен лишь результат.Результат чего? Завуалированного высасывания из пальца?
Походу, "простому обывателю" хватает и результата креатива рекламщиков-пиарщиков.В общем, довольно неуклюжее оправдание мороникса.
Фроникс сложно заподозрить в "подыгрывании" Windows. Есть тестовый пакет и результаты его работы. Что вам еще не хватает?
> Фроникс сложно заподозрить в "подыгрывании" Windows. Есть тестовый пакет и результаты его работы. Что вам еще не хватает?И правда, главное ведь Правильные Результаты, а не их корректность!
И чего это я нос морщу? Не вантузятник ли случайно?
*рукалицо.жпг*
> Предлагаю обратное: сходить на фронтамКуда-куда?
Дико извиняюсь. Писал на планшете...
в винде/ntfs похожая штука есть начиная то ли с висты, то ли с семёрки, TxF называется. вот только сейчас оно объявлено устаревшим и, похоже, скоро его выкинут вообще. не знаю, почему его решили выкинуть, но, вероятно, есть какие-то серьёзные причины, раз после ~десяти лет эксплуатации решили повернуть назад
а почему в венде инсталляторы так долго работают?не из-за этих ли транзакций?
Не, там просто надо мышкой водить над прогрессбаром, иначе установка не идёт.
Мамонне надо поклониться - и пойдет.
Думаю нет. Обычный инсталлятор должен уметь устанавливать на хр и устанавливать на фат32. Поддерживать два разных способа установки достаточно накладно для разработчика инсталлятора, я бы не стал заморачиваться...хотя, может в каком-то новомодном инсталляторе и реализовали...
> не знаю, почему его решили выкинутьвот тут
https://docs.microsoft.com/en-us/windows/desktop/FileIO/perf...
пишут что тормозное шо ппц, и если использовать не для метаданных, то, типа, сами виноваты.А документация к KTM выглядит как-то вот так:
https://docs.microsoft.com/en-us/windows/desktop/api/KtmW32/...
- а потом они удивляются, "чой та так мало сторонних проектов используют наш чудесный недодокументированный интерфейс?"
journaled data - никогда не было быстрым.
> journaled data - никогда не было быстрым.для ext4, кстати, не факт - разумеется, данные должны писаться специфическим образом, и журнал на отдельном быстром устройстве, а не "как всегда".
лет, кажись, десяток назад, жевали мы с Green (кто понял - респект), тогда еще не продавшимся Sun, эту булочку, по грубым прикидкам, выходило что можно. К сожалению, я быстро сбежал из конторы, где это можно было проверить. С тех пор появились всякие nvme, а вот hdd, вроде, сильно быстрее не стали.
так что для TxFS я бы не зарекался. У MS получилось так себе, но они, похоже, и не старались.
(для незамутненных из соседнего тредика - windows installer как раз предлагается ms в качестве _альтернативы_ транзакционной ntfs)
Т.е. они в ядро добавили новые вызовы и работать с этой ФС надо только с языками, которые подерживают вызовы ядра. Т.е. какая-нибудь Java-программа ничего с этого не поимеет. И нафиг это нужно где-то, кроме узкой ниши?
> Т.е. они в ядро добавили новые вызовы и работать с этой ФС надо только с языками, которые
> подерживают вызовы ядра.угу, ведь библиотеки отменили еще, кажется, до вашего рождения?
> Т.е. какая-нибудь Java-программа ничего с этого не поимеет.
жабист должен страдать...зачеркнуто...пользоваться орацле и не мечтать о другом.
>> Т.е. они в ядро добавили новые вызовы и работать с этой ФС надо только с языками, которые
>> подерживают вызовы ядра.
>угу, ведь библиотеки отменили еще, кажется, до вашего рождения?Какой лютый бред... Ну кто побежит во все библиотеки ко всем языкам встраивать это поделие? Что мешало создать псевдофайл /proc/transaction - открытие его означает начало транзакции, закрытие - коммит, а unlink - rollback, например?
костыль к ext4
пока круче fat32 ничё не придумали
что за глупости? Давно мы все придумали, exfat!кстати, самсунь втащил его и в вашу прекрасную систему. (а то у него телевизоры флэшки хреново читали)
Пингвины, роясь на свалке технологий, нашли обрывки концепта WinFS