Почему rename () занимает больше времени, когда сначала вызывается fsync ()?

Я наконец нашел его, это было проще, чем я себе представлял: 7z l -slt | grep -c 'Путь = [^ /] * $' .

0
02.06.2019, 21:18
1 ответ

Основываясь на описании фиксации, я полагаю, что задержки переименования ()вызваны журналом синхронизации Btrfs :после регистрации нового имени . Это было добавлено в ядре v4.19.

Make the logging of the new file name (which happens when creating a hard link or renaming) persist the log.

This approach not only is simpler, [...] but also gives us the same behaviour as ext4, xfs and f2fs (possibly other filesystems too).

Я не верю, что второе предложение верно!

Чтобы быть справедливым, я должен отметить, что dpkgзабывает fsync ()каталоги, содержащие файлы, прежде чем он запишет пакет как правильно установленный. Но такое поведение btrfs не совсем соответствует остальной части Linux.

Я не верю, что XFS синхронизирует новую запись каталога внутри переименования ()(, т.е. намеренно ждет, пока оно сохранится ). Мое предположение против любых операций синхронизации внутри переименования XFS ()частично основано на в этой теме:https://marc.info/?l=linux-xfs&m=139863577410237&w=2

Для ext4 я упомянул доказательство того, что fsync()может синхронизировать новую запись каталога до ее возврата. Но я не верю, что переименование ext4 ()делает это.

Я ссылался на недавние обсуждения AIO fsync ()операций и того, как они могут обеспечить эффективную пакетную обработку обновлений метаданных. Гипотетическое переименование AIO ()не обсуждалось особо, потому что обычно предполагается, что переименование ()не является синхронной операцией!

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


Я думаю, что задержки переименования ()должны быть вызваны BTRFS_NEED_LOG_SYNC, возвращенными из последней строки btrfs _log _new _name().

Я нашел это с помощью offcputime . Он агрегирует время ожидания по трассировке стека. Трассировки стека выглядят так:

io_schedule_timeout
wait_for_completion_io
write_all_supers
btrfs_sync_log
btrfs_sync_file
do_fsync
__x64_sys_fsync
do_syscall_64
entry_SYSCALL_64_after_hwframe
-                dpkg (23528)
    9735954

io_schedule_timeout
wait_for_completion_io
write_all_supers
btrfs_sync_log
btrfs_rename2
vfs_rename
do_renameat2
__x64_sys_rename
do_syscall_64
entry_SYSCALL_64_after_hwframe
-                dpkg (23528)
    9147785

io_schedule
bit_wait_io
__wait_on_bit
out_of_line_wait_on_bit
write_all_supers
btrfs_sync_log
btrfs_sync_file
do_fsync
__x64_sys_fsync
do_syscall_64
entry_SYSCALL_64_after_hwframe
-                dpkg (23528)
    4478158

io_schedule
bit_wait_io
__wait_on_bit
out_of_line_wait_on_bit
write_all_supers
btrfs_sync_log
btrfs_rename2
vfs_rename
do_renameat2
__x64_sys_rename
do_syscall_64
entry_SYSCALL_64_after_hwframe
-                dpkg (23528)
    4376109
0
28.01.2020, 03:38

Теги

Похожие вопросы