Ghost files after deletion on JFS filesystem
kanyck opened this issue · 6 comments
Well, I think that most probably it's not squashmount to blame, but I still consider you the right person to ask..
I use squashmount on my Gentoo desktop and it works just fine. However, when I tried to set it up on a laptop (with nearly identical squashmount.pl), it screws up. After some file is deleted it doesn't disappear as it should but is still there yet unreadable:
ls: cannot access 'FILENAME': No such file or directory
???????????? ? ? ? ? ? FILENAME
The systems differ in kernel versions (4.19 on the laptop) and underlying FS (xfs vs jfs on the laptop).
The kernel config options that I consider to be relevant look the same.
I ran out of ideas where to look...
Check with squashmount list whether really the same tools are used. For overlay or overlayfs, a possibility might be that the underlying FS does not support extended attributes.
Addendum: extended attributes are not a property of the filesystem type but of the kernel configuration for it and perhaps of mount and/or /etc/fstab options.
The problem is that I cannot see any differences -- neither in squashmount list output nor in kernel options nor mount output, etc.
As for kernel config, XATTR and JFS never meet. So I suppose xattr are always on. I checked even hidden (unconfigurable) config options.
I checked deleted files on both systems -- both are character special 0, 0. Looks like a kernel bug in overlay_fs. Will try to upgrade a kernel to see.
BTW -- how can I undo the squashmount and restore the original file tree? I found no command description -- neither here nor on help text provided -- only options. Without that the system is nearly unusable.
I don't know whether JFS supports XATTR.
both are character special 0, 0
Yes, and some XATTR entries mean that it is deleted.
how can I undo the squashmount and restore the original file tree
unsquash squashfile (in the corresponding directory). This is not worth writing a wrapper.
I don't know whether JFS supports XATTR.
Well, it does. Theoretically. Because there is
CONFIG_JFS_POSIX_ACL
CONFIG_JFS_SECURITY
that have to use xattr. And I suspect that xattr are there only if at least one of these options is set. Also, as far as I built new kernel, I may see fs/jfs/xattr.o in there.
However is still doesn't work! My last idea is that xattr probably has to be there at the time the FS is created... otherwise I can't explain what's going on... at least I haven't found anything relevant.
So I gave up for now. Maybe I'll find some time to fiddle with it some more.
This is not worth writing a wrapper.
Fair enough.
unsquash squashfile
Not exactly so
unsquashfs squashfile creates extra level, namely squashfs_root directory, so you have etier to lift up all its content and delete it, or, from the upper directory rmdir the target then
unsquashfs -d target target.mount/target.sfs
Please add this to the docs.
Closing so far. Will let you know if I find the solution.
Changed / to EXT4, all my mystique issues are gone now. Sorry I took your time.