Короткий ответ
Удаление fuse
, вероятно, приведет к невозможности монтировать файловую систему.
FUSE является Filesystem в Userspace, который означает, что есть в пользовательском пространстве программы, которая обрабатывает все операции, выполняемые на этой конкретной файловой системе ( в то время как без плавких поддержки файловой системы работает в) ядрах системы . Это может быть ntfs-3g
в вашем случае; даже если это не так, история в целом такая же.
Все конкретные реализации FUSE зависят от fuse
пакета и ntfs-3g
находятся среди них (ну, формально это предварительная зависимость, но здесь нет никакой разницы ). Это означает, что вы не можете удалить fuse
и заставить ntfs-3g
(или другую программу FUSE) работать.
Что действительно беспокоит вас, так это наличие .fuse_hidden
файлов (сравните: проблема XY ). Остальная часть моего ответа посвящена этой проблеме.
Контекст
Похоже, вы можете игнорировать .fuse_hidden
файлы, как указано здесь: Что такое .fuse_hidden
файл и почему они существуют?
Ответ на Как удалить .fuse_hidden
файлы? сравнивает поведение FUSE с NFS:
Это похоже на то, что происходит, когда вы удаляете файл, открытый другой системой при монтировании NFS.
и поведение NFS объясняется здесь . Оттуда:
Что происходит, когда файл открывается клиентом и удаляется? Файл должен иметь имя, чтобы клиент, у которого он открыт, мог получить к нему доступ. Но когда файл удален, ожидается, что после этого файла с таким именем больше не будет. Таким образом, серверы NFS превращают удаление открытого файла в переименование: файл переименовывается в
.nfs…
(.nfs
за которым следует строка букв и цифр).
Это все потому, что файл в Linux можно удалить, пока он открыт процессом . Этот механизм работает с локальными файловыми системами на основе inode (например, с семейством ext), но его необходимо каким-то образом эмулировать, если доступ к файлам зависит только от их имен. Я считаю, что ситуация с NTFS несколько сложна. Вы можете найти некоторые интересные комментарии и ссылки по ссылке выше.
Ну, ntfs-3g
может имитировать общее поведение Windows и запретить удаление файла, когда он используется. Проблема заключается в том, что многие программы Linux ожидают, что они могут удалить файл, который они все еще используют. Это довольно умно.
Предположим, вашей программе нужен временный файл. Он создает один, открывает его и немедленно удаляет - и Linux это разрешает. Отныне задача фактического освобождения дискового пространства (когда файл больше не нужен) - чужая задача: ядро или FUSE. Эта задача будет выполнена изящно, даже если ваша программа неожиданно умирает или насильственно убивается.
С другой стороны, если ваша программа не может удалить файл заранее, ее работа по-прежнему заключается в ее очистке; неожиданное завершение может оставить «заброшенный» временный файл. А что если кто-нибудь еще откроет тот же файл? Тогда ваша программа не может удалить его, даже когда все готово, и все в порядке.
Хорошо использовать этот способ обработки файлов в Linux. Файлы как .fuse_hidden
или .nfs
являются ценой этой философии, и они будут удалены в конце концов. Но скажем, что-то пошло не так, и они не будут. Их по-прежнему относительно легко обнаружить во время ручного обслуживания, в то время как в Windows вы можете «оставить» файлы и не знать об этом. Способ Linux кажется мне гораздо более аккуратным подходом.
Некоторые тесты
Мой испытательный стенд:
# whoami root # cat /etc/issue Ubuntu 16.04.2 LTS \n \l # uname -a Linux foobar 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux # dpkg -l | grep ntfs-3g ii ntfs-3g 1:2015.3.14AR.1-1ubuntu0.1 amd64 read/write NTFS driver for FUSE
Подготовка точек монтирования:
# mkdir /mnt/ext4 /mnt/ntfs
Подготовка файловых систем:
# truncate -s 20M image-ext4 # truncate -s 20M image-ntfs # mkfs.ext4 -Fq image-ext4 # mkfs.ntfs -FqQ image-ntfs
( mkfs.ntfs
Болтливый вывод опущен.)
Монтаж:
# mount image-ext4 /mnt/ext4/ # mount image-ntfs /mnt/ntfs/
Начальное использование диска:
# df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 172K 17M 1% /mnt/ext4 /dev/loop1 20M 2.5M 18M 13% /mnt/ntfs
Создание файлов:
# dd if=/dev/urandom bs=1M count=10 | tee /mnt/ext4/file > /mnt/ntfs/file 10+0 records in 10+0 records out 10485760 bytes (10 MB, 10 MiB) copied, 0.645865 s, 16.2 MB/s
Использование диска:
# df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 11M 6.8M 60% /mnt/ext4 /dev/loop1 20M 13M 7.6M 63% /mnt/ntfs
Открытие файлов, затем удаление:
# exec 3<> /mnt/ext4/file # exec 4<> /mnt/ntfs/file # rm /mnt/ext4/file /mnt/ntfs/file
Использование диска:
# df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 11M 6.8M 60% /mnt/ext4 /dev/loop1 20M 13M 7.6M 63% /mnt/ntfs
Таким образом, несмотря на удаление, дисковое пространство все еще используется. Это потому, что файлы все еще открыты.
Актуальные файлы:
# ls -A /mnt/ext4/ /mnt/ntfs/ /mnt/ext4/: lost+found /mnt/ntfs/: .fuse_hidden0000000200000001
На этом этапе я делаю копии файловых систем (для последующего сравнения). В общем, я знаю, что не следует делать этого, пока они монтируются, но идея состоит в том, чтобы имитировать полный сброс, прежде чем я закрою файлы. Тем не менее, я хочу, чтобы скопированные файловые системы были чистыми, поэтому sync
команда. Кроме того, эта --reflink=always
опция позволяет мне делать копии, подобные снимкам, в моей файловой системе Btrfs, где image-ext4
и image-ntfs
хранятся; в этом тесте равнина cp
должна работать так же.
# sync # cp --reflink=always image-ext4 copy-ext4 # cp --reflink=always image-ntfs copy-ntfs
Я могу проверить, если copy-ext4
это чисто:
# fsck.ext4 copy-ext4 e2fsck 1.42.13 (17-May-2015) copy-ext4: clean, 11/5136 files, 1849/20480 blocks
К сожалению нет fsck.ntfs
.
Давайте продолжим с оригинальными файловыми системами. Закрытие файлов:
# exec 3>&- # exec 4>&-
Использование диска:
# df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 172K 17M 1% /mnt/ext4 /dev/loop1 20M 2.5M 18M 13% /mnt/ntfs
Содержание:
# ls -A /mnt/ext4/ /mnt/ntfs/ /mnt/ext4/: lost+found /mnt/ntfs/:
Не .fuse_hidden
файл не больше и дисковое пространство снова свободно. Файл исчезает, когда он больше не нужен.
Давайте посмотрим, что происходит после имитации сброса, когда файлы не были закрыты должным образом. Монтажные копии:
# umount /mnt/ext4 /mnt/ntfs # mount copy-ext4 /mnt/ext4/ # mount copy-ntfs /mnt/ntfs/
Использование диска:
# df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 172K 17M 1% /mnt/ext4 /dev/loop1 20M 13M 7.6M 63% /mnt/ntfs
Актуальные файлы:
# ls -A /mnt/ext4/ /mnt/ntfs/ /mnt/ext4/: lost+found /mnt/ntfs/: .fuse_hidden0000000200000001
Так что это сценарий, когда вы должны вручную удалить .fuse_hidden
файл (ы). Обратите внимание, что если ntfs-3g
бы вы не создавали такой файл и сначала отказывали в удалении, у вас теперь был бы оставшийся файл со старым именем; Вы бы сделали это даже без перезагрузки, а это означает еще больше обслуживания.
Я считаю, что файловые системы, основанные на инодах, вообще не нуждаются в таком обслуживании.
Очистка:
# umount /mnt/ext4 /mnt/ntfs # rmdir /mnt/ext4/ /mnt/ntfs/ # rm image-ext4 copy-ext4 image-ntfs copy-ntfs