LINUX.ORG.RU

fsck |/dev/sda1: entry ... has filetype set. fsck |CLEARED

 


0

2

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

При запуске fsck.ext4 начал проверять диск и посыпались сообщения:

fsck         |/dev/sda1: entry ... has filetype set. 
fsck         |CLEARED

Похоже, для каждого файла.

Откуда они взялись? Насколько могу судить, ранее это устройство было /dev/sdb, но параметры монтирования у них одинаковы.

UPD: когда диск досканировался, оказалось, что это — диск, с которого я не грузился года с 18-го, но иногда монтировал в новые системы. Могли при этом прописаться дефолтные атрибуты из новых систем, включая filetype?

Ответ: похоже, следствие сыплющегося диска.

★★★★★

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

пропылесосил системный блок (пока соседи не начали стучать по батарее)

Ты его ночью пылесосил? 🤔

Откуда они взялись?

Когда блок навернулся, видимо. Я бы запустил fsck принудительно и нормально посмотрел, что там.

anonymous
()

Могли при этом прописаться дефолтные атрибуты из новых систем, включая filetype?

Не расшифровал. Если у вас fsck 6 часов работал, то и в прошлый раз должно было быть что-то аналогичное. Если я правильно понимаю смысл сообщения «has filetype set» (по комментариям в исходниках ext4.fsck), то оно означает что у файла (точнее inode) был прописан тип Directory, хотя должен быть File. Так, вроде гуглятся ошибки в сторонних драйверах (под винду и др. ОС), которые могут сделать подобное. Но сделать для вновь создаваемых файлов, ни один драйвер не будет сканировать всю ФС и менять filetype у всего.

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

у файла (точнее inode) был прописан тип Directory, хотя должен быть File.

Как я понял, ошибка из-за того, что вообще никакой атрибут стоять не должен, а стоит File.

Не расшифровал. Если у вас fsck 6 часов работал, то и в прошлый раз должно было быть что-то аналогичное.

Возможно ли присвоение этого атрибута при обращении к этим файлам, например, при копировании/перемещении их из одной директории в другую, если этот диск монтировали на запись в систему, где корневой диск использует атрибуты, а дополнительный — нет?

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

В принципе, возможно, при копировании/перемещении файла с его атрибута может быть что угодно. Но, я во внутренностях ни ext4, ни fsck.ext4 особо не разбираюсь. Вот, сейчас обнаружил, что extFS имеет такой флаг (из man):

filetype
   This feature enables the storage of file type information in di‐
   rectory entries.  This feature is supported by ext2,  ext3,  and
   ext4.
То есть, возможно, именно про это флаг идёт речь, допустим, ФС была создана без этого флага, а потом его включили или он сам включился мутацией бит в суперблоке. Тогда, действительно, у всех direntry будет, с точки зрения fsck, неправильное значение в этом поле.

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от mky

возможно, именно про это флаг идёт речь

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

его включили или он сам включился мутацией бит в суперблоке.

«Мутация» — вроде сбоя на диске?

Пока у меня 2 версии:

  1. Эта фича доступна с 2.2.0, но по умолчанию отключена. Возможно, я впервые включил её, когда форматировал новый диск несколько лет назад. Я скопировал на новый систему, с автоматическим добавлением метаинформации файлов в процессе, затем какое-то время грузился с нового диска, монтируя старый в /mnt, и за это время к файлам на старом добавилась метаинформация. Согласно мануалу, так быть не должно. Поэтому я и создал тему.

  2. Либо я включил эту фичу когда собирал компьютер в начале 2010-х. Через несколько лет, когда диск начал глючить, купил новый диск, отформатировал его с этой же фичей, скопировал на него систему со старого, сделал новый основным, оставив старый диск в системном блоке. В какой-то момент отключил эту фичу, но fsck не прогонял. Учитывая, что я под конец из-за глюков очень часто гонял fsck, и не было причин отключать эту фичу, это выглядит странно. Но если сбой в суперблоке может отключить этот флаг, не вызвав никаких других ошибок, то выглядит правдоподобно.

question4 ★★★★★
() автор топика
Последнее исправление: question4 (всего исправлений: 1)
Ответ на: комментарий от question4

Да, сбой на диске, или в памяти компа, ведь если в блочном устойстве нужно поменять всего 1 бит, то в ОЗУ и обратно предаётся весь блок. Я не помню, суперблок каким-нибудь CRC защищён или нет.

это выглядит странно.

Ошибка «has filetype set» не гуглится, значит у вас единичный странный случай, наука их не изучает :)

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

по делу надо всегда в наше время следить за смартом.

а fsck на ломающемся диском может только ухудшить ситуацию.

причём на любой системе (linux, windows, solaris, etc.)

filetype скорее всего следствие неустойчивого чтения с диска.

ещё такое бывает от битого ОЗУ.

по факту надо лезть в исходники и смотреть, в каком месте оно выводится, вангую что там будет участвовать 7ой байт в соответствующем вхождении о файле в папке:

file type: EXT2_FT_DIR=2 или EXT2_FT_REG_FILE

Table 4.2. Defined Inode File Type Values
Constant Name Value Description
EXT2_FT_UNKNOWN 0 Unknown File Type
EXT2_FT_REG_FILE 1 Regular File
EXT2_FT_DIR 2 Directory File
EXT2_FT_CHRDEV 3 Character Device
EXT2_FT_BLKDEV 4 Block Device
EXT2_FT_FIFO 5 Buffer File
EXT2_FT_SOCK 6 Socket File
EXT2_FT_SYMLINK 7 Symbolic Link

PS: вот кстати и man подтверждает:

filetype

This feature enables the storage of file type information in directory entries. This feature is supported by ext2, ext3, and ext4.
mumpster ★★★★★
()
Последнее исправление: mumpster (всего исправлений: 1)