| 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.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 +/– |
 У меня круче было. Полночи изобретал солнечный коллектор на вакуумных трубках. С утра еду в магазин стройматериалов, а китайцы уже сделали, все что я за ночь придумал, и к нам в магазин завезли. )))))
| | |
|
| 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 З... большой текст свёрнут, показать | | |
|
|
|
| 5.47, mickvav (?), 12:56, 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, да и в целом в ядре постоянно что-то меняется незначительное.
| | |
|
| 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.11, angra (ok), 06:08, 18/07/2018 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Если кто-то постоянно пишет (например в лог), то другие процессы будут абортиться на попытках доступа
Во-первых, абортятся не процессы, а транзакции этих процессов, сами процессы продолжат нормально выполняться
Во-вторых, можно спокойно читать лог без транзакций. А кому-то стоит подумать, зачем он использует чтение лога внутри транзакции.
В-втретьих, неплохо бы программисту хоть чуть-чуть понимать как надо работать с транзакциями/блокировками. То есть не держать транзакцию/блокировку дольше необходимости и правильно обрабатывать ошибки при commit. И тогда, о чудо, никакой проблемы не будет.
> Вобщем, я бы прикопал эту ФС на какое-то время.
Если что-то не подходит для тебя, то может это лично тебе не надо этим пользоваться.
| | |
| |
| 3.37, Андрей (??), 11:05, 18/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Если что-то не подходит для тебя, то может это лично тебе не надо этим пользоваться.
Так человек и написал же "*я* бы прикопал" вместо типичного "такое не надо, закопать".
| | |
|
| |
| 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.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. Про блокировки сказали выше, похоже, что проект является чьим-то курсачом.
| | |
| |
| |
| 3.77, Аноним (-), 17:28, 18/07/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
В которой из них нет? Намедни уже даже геи из монгодб про acid вещали.
| | |
| 3.86, Аноним84701 (ok), 19:41, 18/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
 >> если в бд уже есть свой acid
> А если нет?
Если в БД нет ACID, то это значит, что она прекрасно обходилась и обходится (хотя бы в сферической теории) без него.
В смысле, предрекаемое некоторыми комментаторами "Этим БД только не хватало такой ФС. И уж теперь-то вот развернемся-заживем! Ух!" выглядит несколько недостоверно.
Ваш Кэп.
| | |
|
|
| |
| 2.27, x3who (?), 09:58, 18/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
Видимо, ровно так же, как повела бы себя та, журналируемая ФС, поверх которой крутится эта транзакционная нахлобучка.
| | |
|
| 1.18, Аноним (18), 07:36, 18/07/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
В Qt есть класс QSaveFile (не путать с обычным QFile), сразу про него вспомнил как прочитал новость. Не то же самое, но тоже можно реализовать запись в несколько файлов, а если ошибок не возникло, сделать commit, правда по отдельности для каждого файла. Класс QSaveFile в первую очередь преднозначен чтобы не потерять данные в процессе полной перезаписи всего файла (сохранится прошлая версия файла).
| | |
| |
| |
| 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 [^] [^^] [^^^] [ответить]
| +/– |
 А кто в здравом уме, в наше время хранит такие данные в чистой файловой системе?
| | |
| |
| |
| 5.104, bOOster (ok), 08:43, 20/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ну а теперича обьективно - каковы плюсы хранения всего этого добра в файлах то?
| | |
|
|
| 3.48, немезидеЦ (?), 13:00, 18/07/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Допустим у вас есть два файла Ф1 и Ф2
А где в новости указание "транзакция в файловой системе вцелом"?
Разве речь идет не о конкретном одиночном файле?
А про межфайловой транзакции всё равно придется думать конкретному прикладному контролеру!
| | |
|
|
| 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 +/– |
 поддержка двухфазного коммита есть?
если нет -- то могут засунуть эту поделку обратно
| | |
| |
| |
| |
| 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 [^] [^^] [^^^] [ответить]
| +/– |
Предлагаю обратное: сходить на фронтам и посмотреть сравнение производительности десяточку с линуксами, и там же найти берут "что будет соскоростью если выполнить все ненужное из нее". Интересненько...
| | |
| |
| |
| 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 +/– | И правда, главное ведь Правильные Результаты, а не их корректность И чего это ... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 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 +/– |
Не, там просто надо мышкой водить над прогрессбаром, иначе установка не идёт.
| | |
| 3.82, Нанобот (ok), 18:17, 18/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
Думаю нет. Обычный инсталлятор должен уметь устанавливать на хр и устанавливать на фат32. Поддерживать два разных способа установки достаточно накладно для разработчика инсталлятора, я бы не стал заморачиваться...хотя, может в каком-то новомодном инсталляторе и реализовали...
| | |
|
| |
| |
| 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, например?
| | |
|
|
| |
| 2.108, ms (??), 18:52, 21/07/2018 [^] [^^] [^^^] [ответить]
| +/– | |
что за глупости? Давно мы все придумали, exfat!
кстати, самсунь втащил его и в вашу прекрасную систему. (а то у него телевизоры флэшки хреново читали)
| | |
|
| 1.102, abi (?), 11:26, 19/07/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Пингвины, роясь на свалке технологий, нашли обрывки концепта WinFS
| | |
|
