LINUX.ORG.RU

overlayfs: bad index found (index=index/..., ftype=2000, origin ftype=8000).

 


0

2

Мы делаем и продаем программно-аппаратный комплекс, т.е. железку с софтом.

Внутри стоит крайне порезанная убунта с нашим софтом. Убунта запакована в squashfs образ, который лежит на флешке.

Поверх него монтируется раздел с настройками через overlayfs.

Иногда после неприятной перезагрузки всё ломается и подмонтировать всё таким пирогом не получается.

Сообщение при этом в ядре от overlayfs:

overlayfs: bad index found (index=index/00fb1d000100000000000000000000000000000000c100000000000000, ftype=2000, origin ftype=8000).

Как мы с этим работали?

Проблема где-то в районе: https://vcs.cs.uchicago.edu/kauffman/ubuntu-mainline-crack/blob/master/fs/overlayfs/namei.c#L724

Не знаю, будет ли ещё доступен код по ссылке, так что немного покажу его:

	} else if (ovl_dentry_weird(index) || ovl_is_whiteout(index) ||
		   ((inode->i_mode ^ d_inode(origin)->i_mode) & S_IFMT)) {
		/*
		 * Index should always be of the same file type as origin
		 * except for the case of a whiteout index. A whiteout
		 * index should only exist if all lower aliases have been
		 * unlinked, which means that finding a lower origin on lookup
		 * whose index is a whiteout should be treated as an error.
		 */
		pr_warn_ratelimited("overlayfs: bad index found (index=%pd2, ftype=%x, origin ftype=%x).\n",
				    index, d_inode(index)->i_mode & S_IFMT,
				    d_inode(origin)->i_mode & S_IFMT);
		goto fail;

К сожалению, по сути единственный рабочий способ на сегодня — выполнять самостоятельный overlay-fsck из initrd на загрузке. Для этого надо кусочком кода обойти все файлы на слоеной ФС и те, которые не получится просто открыть, надо удалить из upper dir (т.е. непосредственно с rw раздела).

Ещё workdir должен быть опустошен перед собиранием пирога.

вот такая грустная история =(

★★★★★

Последнее исправление: max_lapshin (всего исправлений: 1)

и те, которые не получится просто открыть, надо удалить из upper dir (т.е. непосредственно с rw раздела)

т.е. данные (настройки) всё равно могут потеряться?

system-root ★★★★★
()

Откуда этот index вообще приезжает? Может в нём просто мусор какой-то после такой ситуации?

А, вижу, в 688 строке. И прикол, до всех проверок его уже в 702 используют.

deep-purple ★★★★★
()
Последнее исправление: deep-purple (всего исправлений: 1)

Отредактируй заголовок, он слишком длинный и ломает страницу при просмотре через мобильник.

izzholtik ★★★
()
Ответ на: комментарий от system-root

да, могут. Честно говоря, у нас такое было только на /var разделе, оттуда стираем не особо жалея

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от max_lapshin

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

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

да, надо фиксить, но я то это делать не буду =(

max_lapshin ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.