XFS - как не изменять mtime при записи в файл? - PullRequest
2 голосов
/ 25 июня 2011

У меня есть файл, a.dat, который составляет 1 ГБ и находится на диске. По соображениям производительности я повторно использую этот файл и просто перезаписываю его содержимое по мере необходимости, а не создаю новый файл и позволяю ему расти (каждая операция увеличения должна обновлять свой размер в inode).

Я пытаюсь снизить производительность, и искал на страницах справочника open и mount , чтобы попытаться выяснить, когда обновляются mtime и ctime для файла , Насколько я понимаю, каждый раз, когда вы меняете содержимое файла, обновляются mtime и / или ctime. Так работает xfs?

Если это так, есть ли способ отключить это в Linux? Меня не волнуют mtime и ctime, и я бы не стал платить за их обновление при каждой операции записи.

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

РЕДАКТИРОВАТЬ В ОТВЕТЕ НА ОТВЕТ

Для пояснения, я пишу на SSD, и выжимание из SSD каждой операции, которую я могу, чрезвычайно важно. SSD теоретически может обрабатывать порядка 25K операций в секунду, и каждая из них важна для меня. Я не хочу, чтобы кто-либо из них был потрачен впустую на что-либо, кроме записи в мои файлы. На этом примечании, на самом деле у меня есть 200 1GB файлов на моем диске, на который я пишу. Я пытался упростить проблему с моим вопросом выше.

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

1 Ответ

3 голосов
/ 25 июня 2011

См. man 2 stat для семантики mtime и ctime. На практике mtime и ctime будут обновляться в копии inode в памяти и асинхронно выгружаться на диск.

Вы не можете пропустить обновление mtime в inode без серьезных взломов ядра, и если вы действительно думаете, что копирование с одного 32-битного счетчика в другое место в памяти замедляет вас, вы ошибочно пытаетесь оптимизировать быструю часть write(2).

Хотите повысить производительность записи файла размером 1 ГБ? Добавьте больше памяти для использования кеша блоков и забудьте о mtime.

добавлено в ответ на комментарий

Синхронная запись не обеспечит безопасность в каком-либо значимом смысле, поскольку вытянутый шнур питания в середине записи на диск не помогает при синхронизации; Вот почему используются журнальные файловые системы, такие как xfs и ext3 +. Лучшее, на что вы можете надеяться - это последовательность перед лицом неудачи.

Вы, похоже, желаете уверенности, что записанные данные отлиты в камне, что принципиально невозможно, даже если вы создаете RAID с резервными буферами записи SRAM с батарейным питанием, поскольку что-то может всегда давать сбой до того, как биты будут зафиксированы. Запись необработанного тома обеспечивает вам еще меньшую защиту, чем журнальная файловая система.

Если вы уточните свое намерение по дизайну в своем вопросе, возможно, будет возможен лучший ответ. На инстинктивном уровне, даже несмотря на то, что время записи длиннее, для маленького файла объемом 1 ГБ флэш-память кажется мне менее подверженной ошибкам, чем вращающиеся оксиды, но это не формальное объявление.

...