Это не решение, а как максимум — временный workaround!

Первым (и необходимым) шагом к решению является разрешение записи core-dump'ов (могу поделиться материалами на заметку как и почему я полагаю правильным делать это).
Потом (только потом) — убить процесс заслуженным SIGABRT.
Вручить дамп разработчикам.

И только после установки скорректированного (в идеале — исправленного) пакета проблему можно полагать решённой.

К вопросу же _причины_ её появления отмечу достаточно давнюю проблему интерпретации (совместимости и трансляции) данных пользовательского профиля.
В современной действительности проглядывающей лишь при обновлении FF/TB (ну и с хвостами в… например, гентушном руководстве по обновлению XFce).

#cid87567, imen

Первым (и необходимым) шагом к решению является разрешение записи core-dump'ов (могу поделиться материалами на заметку как и почему я полагаю правильным делать это).
Потом (только потом) — убить процесс заслуженным SIGABRT.
Вручить дамп разработчикам.

Вот у меня проблема, здесь и сейчас. После твоих рекомендаций моя проблема исчезнет?

И только после установки скорректированного (в идеале — исправленного) пакета проблему можно полагать решённой.

Сколько времени это займёт?

Нужна ли данная заметка человеку, который умеет снять дамп и отправить его разработчику?

#cid87875,

Вот у меня проблема, здесь и сейчас.

Отвечу словами Карлсона: «Спокойствие, только спокойствие…»

После твоих рекомендаций моя проблема исчезнет?

Исходные данные заметки потрясают полнотой и детализацией: ни архитектура, ни хотя бы версия gvfs, ни тем более версия компиллятора, которым оно собиралось не упомянуты.
Поэтому первым делом верну вопрос: выполнение описанных действий окончательно решает проблему или только временно снимает симптомы?

Во-вторых, полезно придерживаться принципа "всегда поступать правильно". Даже если это не сулит быстрых непосредственных выгод.

Сколько времени это займёт?

Послать -6, оформить претензии и залить дамп — минут 10-15.

Нужна ли данная заметка человеку, который умеет снять дамп и отправить его разработчику?

Наличие навыков _правильной_ работы с OpenSource, вкупе с наличием навыков, позволяющих самостоятельно промыслить описанный workaround не гарантирует наличия времени, необходимого для промышления оного.
Так что — может и пригодиться.

Но дело не столько в этом, сколько в потакании чуждым стереотипам, вместо кропотливой работы над распространением правильных приёмов.
А ведь эта экономия чревата тем, что в один прекрасный момент эти привнесённые стереотипы объявят обязательной нормой.
Ты уверен в том, что тебе это нужно?

нужно просто дать команду rm -rf ~/.local/share/gvfs-metadata и все.

Не всё. Через некоторое время этот процесс снова запускается и колотит винт. Видимо, это баг самого Гнома. Надо долбить по голове разработчиков.

#cid90507, Dron

Не всё. Через некоторое время этот процесс снова запускается и колотит винт. Видимо, это баг самого Гнома. Надо долбить по голове разработчиков.

Товарищи!
Чем валить всё на крайнего (в данном случае upstream GNOME) вы бы хоть версии (хотя бы больного, хотя проблема может порождаться дистрибутивными патчами и/или взаимодействием с зависимыми библиотеками) называли…

Применительно к описываемому (и вообще) также было бы нелишним посмотреть сообщения буфера ядра (dmesg) и журнал (вот лично ты знаешь как и почему сконфигурирована подсистема журналирования твоего дистрибутива?).

ЗЫ: gvfs (gnome-base/gvfs-1.22.3) есть, GNOME в качестве целостной установки нет (только то, что требуется в качестве зависимостей).
О проблеме нигде кроме этой темы не слышал.

А теперь, внимание, _правильный_ ответ:

Последние наблюдения сняты с amd64-сборки gnome-base/gvfs-1.22.3.
Проблема в не вполне полной и адекватной отработки ошибок.
У меня совершенно аналогичное описываемому поведение gvfs наблюдалось для модуля gvfsd-sftp (и никаких метаданных) при подключении к серверу с некорректным (по мнению данной реализации gvfs) профилем (в данном конкретном частном случае: у пользователя с реальным shell'ом в profile оного прописан вызов другого shell'а — извращение нетипичное и не вполне правильное): процесс не делал ожидаемого и вообще ничего не делал. Кроме выжирания ~100% ресурсов одного ядра процессора.

Возвращаясь к теме заметки:
Пользовательский демон gvfsd-metadata начинает шалить не от того, что ему так подумалось, а от того, что какой-то добрый процесс поломал формат используемых оным демоном файлов.
Соответственно решать проблему нужно по двум линиям: во-первых, расширением перечня обрабатываемых gvfsd-metadata ошибок, и во-вторых — идентификацией виновника повреждения метаданных пользователя (начиная с идентификации повреждений) и исправлением ошибки на его стороне.