The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Для Linux представлена файловая система TxFS с поддержкой ACID-транзакций

17.07.2018 23:44

Группа исследователей из Техасского университета в Остине разработала новую файловую систему TxFS, предоставляющую встроенную поддержку транзакций, удовлетворяющих требованиям ACID (атомарность, согласованность, изолированность, надежность). Код ФС доступен только в виде модифицированных исходных текстов ядра 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 продемонстрировал существенное увеличение надёжности и способность предотвращать повреждения данных и нарушения целостности при сбоях во время выполнения операций с репозиторием.

  1. Главная ссылка к новости (https://www.usenix.org/confere...)
  2. OpenNews: Компания Alibaba открыла код P2P-системы доставки файлов Dragonfly
  3. OpenNews: Инженеры из Google представили глобальную файловую систему Upspin
  4. OpenNews: Представлена LittleFS, компактная файловая система для встраиваемых устройств
  5. OpenNews: Первый выпуск файловой системы Zbox
  6. OpenNews: Значительное обновление файловой системы Bcachefs
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48981-txfs
Ключевые слова: txfs, transaction, acid, ext4
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (103) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 01:19, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Фига они быстрые! Я только месяц назад начал размышлять, как по настоящему транзакционная ФС должна выглядеть, а эти уже реализовали. Молодцы!
     
     
  • 2.3, Андрей (??), 01:33, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Год назад:

    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.

     
  • 2.8, Аноним (8), 04:05, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ...целый месяц!
     
  • 2.36, Аноним (36), 10:55, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Этим программист от пользователя и отличатся, что второй только размышляем, мечтает и хотелки высказывает.
     
  • 2.41, Led (ok), 11:34, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +19 +/
    > Я только месяц назад начал размышлять

    Ка только каникулы начались, так сразу и начал "размышлять"?

     
  • 2.103, ovg (ok), 14:22, 19/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    У меня круче было. Полночи изобретал солнечный коллектор на вакуумных трубках. С утра еду в магазин стройматериалов, а китайцы уже сделали, все что я за ночь придумал, и к нам в магазин завезли. )))))
     
  • 2.109, adolfus (ok), 11:53, 20/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    CICS
     

  • 1.2, Вареник (?), 01:30, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Если базы данных начнут эти расширения поддерживать - то взлетит. Но только в этом случае.
     
     
  • 2.7, x3who (?), 02:52, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Базам данных-то это зачем? У них транзакции свои, нормальные, из коробки.
     
     
  • 3.10, angra (ok), 05:42, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    С одной стороны конечно это так, но с другой:
    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
     
     
  • 4.30, x3who (?), 10:21, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Эффективно они вроде как подменили журнал наката SQLite журналом ФС. Возможно это даёт какие-то преимущества по скорости. Мне вот что только непонятно: БД оперирует записями, а TxFS - объектами ядра, т.е. страницами. Одна страница может содержать много записей. Вот что происходит в TxFS, если мы интенсивно апдейтим/добавляем/читаем записи из множества транзакций, обращаясь к одной и той же странице? Инсерты будут создавать разреженные страницы, содержащие одну или несколько записей, созданные одной транзакцией? Конфликты при доступе на чтение и апдейт к уже закоммиченным данным? Это же вполне реальный юзкейс: приходят данные и как-то обрабатываются, при этом новые данные обычно ложатся рядом и при этом они наиболее востребованы другими приложениями.
     
     
  • 5.46, anonymous (??), 12:54, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Базы точно так же оперируют страницами с данными, записями было б слишком дорого.
     
     
  • 6.52, x3who (?), 13:23, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >  Базы точно так же оперируют страницами с данными, записями было б слишком дорого

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

     
     
  • 7.101, funny.falcon (?), 09:33, 19/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Зависит от БД.
    В sqlite (стоковом) одновременно может быть только один писатель, т.е. ситуации "ты можешь спокойно апдейтить разные записи из разных транзакций" в принципе нет.
    И в классическом режиме (с undo) писатель блокирует читателей тоже, копирует страницы в undo, а меняет их прям на месте.
    Этому режиму транзакционная фс очень поможети вместо того, чтобы выгонять читателей и использовать собственный undo, sqlite может использовать транзакции файловой системы.
     
     
  • 8.105, x3who (?), 11:54, 20/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не совсем так, в классическом Read committed , в худшем случае пишущая транзак... большой текст свёрнут, показать
     
  • 8.106, x3who (?), 03:18, 21/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Почитал немного про SQLite и до меня дошло, что весь ваш пост был про SQLite З... большой текст свёрнут, показать
     
  • 6.107, Очередной аноним (?), 12:03, 21/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Базы оперируют блоками страницами с данными только для чтения записи на носи... большой текст свёрнут, показать
     
  • 5.47, mickvav (?), 12:56, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну соберите стендик, если интересно. Тут ведь как - новая заявленная функциональность требует и новых методов тестирования - стандартно же ФС - это про файлы и неструктурированные данные, а БД - это про структурированные данные и транзакции.
     

  • 1.4, Лис (?), 02:05, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Прикольно.
     
  • 1.5, rm1 (?), 02:22, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > только в виде модифицированный исходных текстов ядра Linux 3.18

    А что на таком новом непроверенном ядре, надо было на 2.6 делать. Тогда бы точно все поняли что намерения серьёзные, и релиз продуман и подготовлен хорошо.

     
     
  • 2.13, пох (?), 07:04, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • –9 +/
    потому что "stable api is no sense", а людям нужна была работающая реализация, а не бесконечная гонка за механическим зайцем.

    лучше спросить¸ зачем они для этой задачи выбрали такую безнадежно больную хрень как линукс, и такую устаревшую и неэффективную fs, вместо того, чтобы использовать хотя бы zfs, пусть даже в виде zol, все проще потом портировать.

    ну то есть понятно, на самом деле, почему - jbd наше всьо...

     
     
  • 3.20, Fracta1L (ok), 08:06, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Опять у ZFS-фанбоев боли, что кто-то не восхищается этим монструозным корявым поделием.
     
     
  • 4.32, нах (?), 10:26, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/

    а что, есть из чего выбирать?
    А если еще и хотя бы попытаться сделать не linux-only ?
    Хотя да, зачем, "нахрен posix, linux ваш новый стандарт!(c)Леннарт-всегда-прав!"
     
     
  • 5.57, Аноним (57), 14:01, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Выбирай: HAMMER на BSD и BTRFS на Linux. А эта твоя zfs - инородный костыль везде, кроме ее родной, но, к сожалению уже дохлой системы.
     
     
  • 6.62, нах (?), 15:18, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Выбирай: HAMMER на BSD и BTRFS на Linux.

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

    и ничего, что "дохлая система" - systemV юникс, у которой "родной" является вовсе не zfs?

     
     
  • 7.68, Annoynymous (ok), 16:02, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это не жертвы синдрома, это жертвы лицензий и юридического крючкотворства. Давайте не будем искажать реальность.
     
     
  • 8.75, нах (?), 17:18, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    более отвратительно мутной лицензии, чем cddl, придумать сложно и вполне может ... текст свёрнут, показать
     
  • 7.84, Аноним (84), 19:13, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >одну из которых уже второй раз переписали с нуля, а другая все-еще-немножечко-не-совсем-окончательно-готова-для, обе кое-как работающие каждая в своей единственно-верной системе

    Понятно, очередной форумный куаретик. Всё там работает нормально, если руки прямые конечно.

    Нормальные аргументы у тебя есть? Или засчитываем слив?

     
     
  • 8.91, нах (?), 20:32, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    тогда тебе сразу засчитаем слив, поскольку твой аргумент насчет инородного ко... большой текст свёрнут, показать
     
  • 6.76, Аноним (76), 17:19, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >HAMMER на BSD

    На Dragonfly BSD, ты хотел сказать. Больше нигде её нет.

    >BTRFS на Linux

    Оно ещё живо?

    Что удивительно, ZFS работает в Linux без каких-либо проблем, так что зачем городить костыли?

     
     
  • 7.92, нах (?), 20:54, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Что удивительно, ZFS работает в Linux без каких-либо проблем, так что зачем городить костыли?

    ну не то чтобы без проблем, но эти проблемы в основном общие, и с иллюмосными тоже.

    а вот проблемы btrfs (о мертвых - лучше помолчим) - линуксонли, и даже их отсутствие у одного анонима - "в каком конкретно ядре? Какого дистрибутива?" (причем пользы с этого знания, чаще всего - никакой, мало кто может взять и вот так разом сменить "неправильный" rhel на "правильный" орацле, даже если какая-то болячка при этом раccосется)


     
  • 6.98, Аноним (98), 00:35, 19/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Выбирай: HAMMER на BSD и BTRFS на Linux

    что из этого - пики точеные?

     
  • 2.17, Аноним (17), 07:32, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > А что на таком новом непроверенном ядре, надо было на 2.6 делать. Тогда бы точно все поняли что намерения серьёзные, и релиз продуман и подготовлен хорошо

    Видимо, разработка началась в момент, когда ядро 3.18 было актуальным, и команда решила, что будет удобнее _завершить_ проект на этом ядре, а потом уже портировать оттестированный рабочий код под более новые версии. Это намного эффективнее, чем переписывание еще не готовой программы при каждом обновлении ядра в погоне за версиями.

     
  • 2.24, Аноним (24), 08:53, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    потому что эта версия используется как основная LTS в куче встраиваемых устройств (естественно, со своими патчами для каждой железки)
     
  • 2.25, asd (??), 09:27, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Потому-что Линус и КО постоянно воротят VFS включая API, да и в целом в ядре постоянно что-то меняется незначительное.
     
  • 2.40, ajp (?), 11:26, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Android?
     
     
  • 3.60, Алексей Михайлович (?), 14:58, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В качестве клиента к БД и сопутствующему.
     
  • 2.53, Аноним (53), 13:34, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Видимо, под 6-й андроид начинали пилить.
     

  • 1.6, x3who (?), 02:50, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не взлетит. В их ФС пока одна транзакция произвела запись в страницу данных и ещё не закоммитила транзакцию, никто не сможет прочитать оригинальное содержимое страницы:

    > 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-hu.pdf

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

    Вобщем, я бы прикопал эту ФС на какое-то время.  

     
     
  • 2.9, Аноним (8), 04:43, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Разве не это ли является примером атомарности?
     
  • 2.11, angra (ok), 06:08, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Если кто-то постоянно пишет (например в лог), то другие процессы будут абортиться на попытках доступа

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

    > Вобщем, я бы прикопал эту ФС на какое-то время.

    Если что-то не подходит для тебя, то может это лично тебе не надо этим пользоваться.

     
     
  • 3.37, Андрей (??), 11:05, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Если что-то не подходит для тебя, то может это лично тебе не надо этим пользоваться.

    Так человек и написал же "*я* бы прикопал" вместо типичного "такое не надо, закопать".

     
  • 2.21, Catwoolfii (ok), 08:32, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    может тогда нужна мультиверсионность?
     
     
  • 3.26, x3who (?), 09:37, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  может тогда нужна мультиверсионность?

    Не знаю, что им нужно. Может витаминов.

    Они в своей брошюрке утверждают, что "TxFS achieves the isolation level of repeatable reads". Вот только беда, ни один уровень транзакции, в т.ч. и repeatable read не подразумевает того, что тразакция будет абортиться на чтении измененных данных там речь только о том, какие именно данные она прочтёт: https://ru.wikipedia.org/wiki/%D0%A3%D1%80%D0%BE

     
  • 2.54, vitalif (ok), 13:40, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати да, транзакции без MVCC это ж жеппа
     
  • 2.69, Annoynymous (ok), 16:03, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Может, просто не стоит использовать эту ФС на /var, а использовать где-то в более подходящих для неё условиях?
     

  • 1.12, Аноним (12), 06:58, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Во-вторых, можно спокойно читать лог без транзакций. А кому-то стоит подумать, зачем он использует чтение лога внутри транзакции.

    Лог конечно читать внутри транзакции никчему, но представьте бинарный формат виртуального жёсткого диска. VHD например. Там блоки фиксированного размера, при записи в один менять весь файл не нужно. Допустим 2 разных блока отобразили в память и начали читать и писать в рамках разных транзакций, а потом закоммитили их. Эта штука похоже так не позволяет, значит не нужна.

     
     
  • 2.14, пох (?), 07:05, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > VHD например.

    и зачем тебе транзакции - для vhd? Нет там никаких транзакций и нахрен они ему не нужны.

    в общем, беги в школу, опоздаешь. Не в курсе ты, зачем нужны транзакции и где применяются, этого в пятом классе еще не проходили.

     

  • 1.15, Аноним (-), 07:17, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Непонятна идея совать это дело в фс, на которой лежит бд, если в бд уже есть свой acid. Про блокировки сказали выше, похоже, что проект является чьим-то курсачом.
     
     
  • 2.70, Annoynymous (ok), 16:04, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > если в бд уже есть свой acid

    А если нет?

     
     
  • 3.77, Аноним (-), 17:28, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В которой из них нет? Намедни уже даже геи из монгодб про acid вещали.
     
  • 3.86, Аноним84701 (ok), 19:41, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> если в бд уже есть свой acid
    > А если нет?

    Если в БД нет ACID, то это значит, что она прекрасно обходилась и обходится (хотя бы в сферической теории) без него.
    В смысле, предрекаемое некоторыми комментаторами "Этим БД только не хватало такой ФС. И уж теперь-то вот развернемся-заживем! Ух!" выглядит несколько недостоверно.

    Ваш Кэп.

     

  • 1.16, Аноним (16), 07:21, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как она себя ведет в случае если есть bad sectors на диске?
     
     
  • 2.27, x3who (?), 09:58, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Видимо, ровно так же, как повела бы себя та, журналируемая ФС, поверх которой крутится эта транзакционная нахлобучка.
     

  • 1.18, Аноним (18), 07:36, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В Qt есть класс QSaveFile (не путать с обычным QFile), сразу про него вспомнил как прочитал новость. Не то же самое, но тоже можно реализовать запись в несколько файлов, а если ошибок не возникло, сделать commit, правда по отдельности для каждого файла. Класс QSaveFile в первую очередь преднозначен чтобы не потерять данные в процессе полной перезаписи всего файла (сохранится прошлая версия файла).
     
     
  • 2.56, yet another anonymous (?), 13:56, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не задумались о гарантиях-то? Ваши телодвижения без ядра --- это потрясание бубном. И даже за ядром ещё железяки есть...
     
     
  • 3.97, Аноним (18), 22:14, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так я и написал же, что это не то же самое. Просто вспомнил про интересный класс, который предназначен для вполне конкретной задачи. А гарантии только господь дать может.
     

  • 1.19, немезидеЦ (?), 07:40, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Это классно конечно, но в прикладном ПО не должно быть привязки к конкретной файловой системе.
    Оптимально - введение флага при открытии файла(типа FLAG_ATOMIC) и ОДНОЙ новой функции типа rollback. Роль "Commit" прекрасно может исполнить тот же flush(..).
     
     
  • 2.31, нах (?), 10:23, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Это классно конечно, но в прикладном ПО не должно быть привязки к конкретной файловой системе.

    "вы прослушали мнение неосилятора configure и #ifdef"

    прикладное ПО тебе в общем-то ничего не должно, а если его авторам не лень добавить возможность эффективной работы при наличии дополнительной возможности - кому-то вполне может оказаться полезным.

    Помимо sqlite у нас есть еще куча софта со своими "типа-базами-данных", не имеющих выделенного "сервера", и перекладывающих механику реализации локов/атомарных операций на нижележащую fs. Впрочем, настоящим тазам банных тоже может оказаться небесполезно, поскольку хранение оракловой бд на raw partitions давно уже немодно, и в любом случае приходится иметь дело с файловыми системами.

    хотя и жаль, конечно, что именно ext4. Будущего у нее, пожалуй, нет.

     
     
  • 3.39, Андрей (??), 11:12, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > хотя и жаль, конечно, что именно ext4. Будущего у нее, пожалуй, нет.

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

     
     
  • 4.42, нах (?), 12:10, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Что касается типичного использования, то как и у других развитых ФС на сегодняшний день.

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

    полагаю, что, при всей моей нелюбви к поделке оракла, btrfs тоже так же вполне можно пользоваться.

    очевидно есть будущее у xfs в редхатовском исполнении. А с ext4 - "жги, тут уже ничего не исправить!"
    Интересно, сервера гугля так и сидят на странной конструкции "ext4-nojournal" ?

     
  • 4.81, Аноним (81), 18:06, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ext4 на стораджах больше 128Т - это очень грустно.
    создавайте / удаляйте файлы в одном каталоге - узнаете много нового.

    А так - проблем нету.

     
     
  • 5.93, нах (?), 21:01, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    там гораздо раньше становится грустно.
    Собственно, нарваться на побочные эффекты причудливого "экономичненького" решения dirhash может любой админ локалхоста, в этом каталоге не так-то и много надо файлов.

    а для нелокалхоста там сплошное непаханное поле граблей и в области журнала (не просто так гугль в свое время от него избавлялся) и в области эффективности, и с надежностью местами "works as intended"... А если у тебя не одна ix86 архитектура, то вообще такие чудеса, что диву даешься...

    ну ладно, зато вот - "эффективная подкладка под патченную sqlite", неплохое применение. Понятное дело, не о 128 терах речь.

    еще б subversion и hg кто-нибудь пропатчил (гиту-то нафиг не надо, на самом деле) - вообще прекрасно было бы.

     
  • 2.34, x3who (?), 10:47, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >  Роль "Commit" прекрасно может исполнить тот же flush(..).

    Думаю, вы не один у нас такой - поэтому объясняю юзкейс.

    Допустим у вас есть два файла  Ф1 и Ф2, в которых лежат счета клиентов.

    Одновременно у вас крутятся несколько процессов, скажем тысяча, которые переводят деньги со счета на счет.

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

     
     
  • 3.43, bOOster (ok), 12:27, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А кто в здравом уме, в наше время хранит такие данные в чистой файловой системе?
     
     
  • 4.50, x3who (?), 13:17, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Так транзакций же в фс доселе не было - вот и не хранят.
     
     
  • 5.104, bOOster (ok), 08:43, 20/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а теперича обьективно - каковы плюсы хранения всего этого добра в файлах то?
     
  • 3.48, немезидеЦ (?), 13:00, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Допустим у вас есть два файла  Ф1 и Ф2

    А где в новости указание "транзакция в файловой системе вцелом"?
    Разве речь идет не о конкретном одиночном файле?
    А про межфайловой транзакции всё равно придется думать конкретному прикладному контролеру!

     
     
  • 4.49, немезидеЦ (?), 13:01, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Извиняюсь, некорректно прочел код.
     

  • 1.29, Аноним (29), 10:15, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > 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).

     
     
  • 2.38, Андрей (??), 11:11, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Но не всех ФС. А ещё нельзя перенести все метаданные, например:
    https://github.com/geany/geany/issues/1049 (закрыто, известная ошибка но решения нет).

    Выдержки из https://wiki.geany.org/config/all_you_never_wanted_to_know_about_file_saving
    [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]

     

  • 1.33, Аноним (33), 10:38, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А как у неё с фрагментацией? Так же как у ext4 (почти отсутствует) или в лучших традициях m$? Если есть возможность откатить изменения, то она их складывает где-то рядом. При этом, по идее, фрагментация должна дико расти.
     
     
  • 2.44, нах (?), 12:35, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Так же как у ext4

    так же
    > (почти отсутствует)

    тебя обманули.

    > или в лучших традициях m$?

    нет, аналога creat() с prealloc у нас нет и не будет.

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

     
  • 2.79, Аноним (81), 17:52, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    это у ext4 нету франгментации ? вы серьезно?.. давайте посмеемся вместе :)
     
     
  • 3.94, нах (?), 21:06, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > это у ext4 нету франгментации ?

    он не видит - значит, нету ;-) это ms что-то перевозбудилась, понапридумывала ненужных предупреждений и спецтулз, и, вот, в результате - перепугала наивных пингвиняток, хотя у нее эта проблема и выражена гораздо меньше, и пути обхода предусмотрены. А в ext4 оценить фрагментированность - не каждому админу локалхоста дано.

    и это он еще про косвенные inodes третьего уровня не в курсе - совершенно отдельная от обычной фрагментации беда.

     

  • 1.35, Xasd (ok), 10:49, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    поддержка двухфазного коммита есть?

    если нет -- то могут засунуть эту поделку обратно

     
     
  • 2.51, x3who (?), 13:19, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В их доке сказано, что есть.
     
     
  • 3.58, Xasd5 (?), 14:40, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    тогда могут не засовывать
     
     
  • 4.71, x3who (?), 16:05, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не факт.. Лучше это сделать самостоятельно, чем ждать пока это сделает кто-нибудь другой.
     

  • 1.45, Куда уходит Ledo (?), 12:45, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Совсем неинтересный стал у вас линукс. Где новости о том, как попрана и опозорена поганая винда? О том как Столлман всем сказал, что так нельзя, а эдак можно? Где новые исошки альт-шигоринса с поддержкой трактора "Богатырь", в конце-концов?
     
     
  • 2.63, Аноним (63), 15:24, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Предлагаю обратное: сходить на фронтам и посмотреть сравнение производительности десяточку с линуксами, и там же найти берут "что будет соскоростью если выполнить все ненужное из нее". Интересненько...
     
     
  • 3.64, Аноним (63), 15:25, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Фроникс.
     
     
  • 4.66, др. Аноним (?), 15:39, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Фроникс.

    Смысл ходить на мороникс и смотреть, если можно сразу из пальца высосать?
    Там же одни и те же тесты в одних и тех же ОСях (только с разницей в месяц) могут различаться как небо и земля, но никаких попыток докопаться до причин регресса/прогресса (регрессия, баг в дровах/железе, измененный конфиг) не предпринимается. Тоже самое для всяких чрезмерных девиаций.
    А предоставляемых деталей недостаточно для каких-то выводов или, тем более, самостоятельного копания.
    Не говоря уже о том, что "тесты" вполне могут запустить и на "похожем" (но не одинаковом) железе.


     
     
  • 5.73, Аноним (73), 16:16, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Простого обывателя причины волнуют слабо. Да и вовсе не должны, на самом деле. Важен лишь результат.
     
     
  • 6.74, др. Аноним (?), 16:54, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Простого обывателя причины волнуют слабо. Да и вовсе не должны, на самом деле. Важен лишь результат.

    Результат чего? Завуалированного высасывания из пальца?
    Походу, "простому обывателю" хватает и результата  креатива рекламщиков-пиарщиков.

    В общем, довольно неуклюжее оправдание мороникса.


     
     
  • 7.83, Аноним (83), 18:40, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Фроникс сложно заподозрить в "подыгрывании" Windows. Есть тестовый пакет и результаты его работы. Что вам еще не хватает?
     
     
  • 8.87, Аноним (87), 19:46, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    И правда, главное ведь Правильные Результаты, а не их корректность И чего это ... текст свёрнут, показать
     
  • 3.65, др. Аноним (?), 15:27, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Предлагаю обратное: сходить на фронтам

    Куда-куда?


     
     
  • 4.72, Аноним (73), 16:15, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Дико извиняюсь. Писал на планшете...
     

  • 1.55, Нанобот (ok), 13:51, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    в винде/ntfs похожая штука есть начиная то ли с висты, то ли с семёрки, TxF называется. вот только сейчас оно объявлено устаревшим и, похоже, скоро его выкинут вообще. не знаю, почему его решили выкинуть, но, вероятно, есть какие-то серьёзные причины, раз после ~десяти лет эксплуатации решили повернуть назад
     
     
  • 2.59, Xasd5 (?), 14:41, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а почему в венде инсталляторы так долго работают?

    не из-за этих ли транзакций?

     
     
  • 3.78, Аноним (-), 17:29, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не, там просто надо мышкой водить над прогрессбаром, иначе установка не идёт.
     
     
  • 4.89, Аноним (89), 20:05, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Мамонне надо поклониться - и пойдет.
     
  • 3.82, Нанобот (ok), 18:17, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю нет. Обычный инсталлятор должен уметь устанавливать на хр и устанавливать на фат32. Поддерживать два разных способа установки достаточно накладно для разработчика инсталлятора, я бы не стал заморачиваться...хотя, может в каком-то новомодном инсталляторе и реализовали...
     
  • 2.61, нах (?), 15:11, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > не знаю, почему его решили выкинуть

    вот тут
    https://docs.microsoft.com/en-us/windows/desktop/FileIO/performance-considerat
    пишут что тормозное шо ппц, и если использовать не для метаданных, то, типа, сами виноваты.

    А документация к KTM выглядит как-то вот так:
    https://docs.microsoft.com/en-us/windows/desktop/api/KtmW32/nf-ktmw32-createtr
    - а потом они удивляются, "чой та так мало сторонних проектов используют наш чудесный недодокументированный интерфейс?"

     
     
  • 3.80, Аноним (81), 17:53, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    journaled data - никогда не было быстрым.
     
     
  • 4.95, пох (?), 21:18, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > journaled data - никогда не было быстрым.

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

    лет, кажись, десяток назад, жевали мы с Green (кто понял - респект), тогда еще не продавшимся Sun, эту булочку, по грубым прикидкам, выходило что можно. К сожалению, я быстро сбежал из конторы, где это можно было проверить. С тех пор появились всякие nvme, а вот hdd, вроде, сильно быстрее не стали.

    так что для TxFS я бы не зарекался. У MS получилось так себе, но они, похоже, и не старались.
    (для незамутненных из соседнего тредика - windows installer как раз предлагается ms в качестве _альтернативы_ транзакционной ntfs)

     

  • 1.85, Аноним (89), 19:36, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Т.е. они в ядро добавили новые вызовы и работать с этой ФС надо только с языками, которые подерживают вызовы ядра. Т.е. какая-нибудь Java-программа ничего с этого не поимеет. И нафиг это нужно где-то, кроме узкой ниши?
     
     
  • 2.96, пох (?), 21:19, 18/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Т.е. они в ядро добавили новые вызовы и работать с этой ФС надо только с языками, которые
    > подерживают вызовы ядра.

    угу, ведь библиотеки отменили еще, кажется, до вашего рождения?

    > Т.е. какая-нибудь Java-программа ничего с этого не поимеет.

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

     
     
  • 3.99, Аноним (89), 01:48, 19/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> Т.е. они в ядро добавили новые вызовы и работать с этой ФС надо только с языками, которые
    >> подерживают вызовы ядра.
    >угу, ведь библиотеки отменили еще, кажется, до вашего рождения?

    Какой лютый бред... Ну кто побежит во все библиотеки ко всем языкам встраивать это поделие? Что мешало создать псевдофайл /proc/transaction - открытие его означает начало транзакции, закрытие - коммит, а unlink - rollback, например?

     

  • 1.100, Аноним (100), 07:50, 19/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    костыль к ext4
    пока круче fat32 ничё не придумали
     
     
  • 2.108, ms (??), 18:52, 21/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    что за глупости? Давно мы все придумали, exfat!

    кстати, самсунь втащил его и в вашу прекрасную систему. (а то у него телевизоры флэшки хреново читали)

     

  • 1.102, abi (?), 11:26, 19/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пингвины, роясь на свалке технологий, нашли обрывки концепта WinFS
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру