What to do with possibly corrupt, un-deletable directory

STREBLO · 2016-09-17 01:19:37

I have a directory '~/.cache/google-chrome/Default/Cache' that I'm not able to delete. I have attempted 'rm -rf' as root, and I even booted into the arch live installer and tried to delete it from there.

I am running zfs on two mirrored ssd's and running a scrub gave no errors.

I am also not able to 'cd' into the directory or run commands like 'ls'. The commands just hang forever. What should I do about this? How do I delete this directory?

Trilby · 2016-09-17 01:36:35

How does rm -rf fail? Is there an error message?

Does ls only fail to list what is *in* the directory, or does it even fail to show the directory? If only the former, what is the ls -l output for the directory itself, or stat output would be even better.

If rm commands return silently but do not have an effect, then perhaps an strace on the rm command would help.

STREBLO · 2016-09-17 02:02:24

No error, it simply never completes. ls never completes as well.

Not sure what to think of this:

strace rm -rf /home/john/.cache/google-chrome/Default/Cache
execve("/usr/sbin/rm", ["rm", "-rf", "/home/john/.cache/google-chrome/"...], [/* 34 vars */]) = 0
brk(NULL)                               = 0x259a000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=177065, ...}) = 0
mmap(NULL, 177065, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc18f0a4000
close(3)                                = 0
open("/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\3\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1951744, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc18f0a2000
mmap(NULL, 3791152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc18eb10000
mprotect(0x7fc18eca5000, 2093056, PROT_NONE) = 0
mmap(0x7fc18eea4000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x194000) = 0x7fc18eea4000
mmap(0x7fc18eeaa000, 14640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fc18eeaa000
close(3)                                = 0
arch_prctl(ARCH_SET_FS, 0x7fc18f0a3480) = 0
mprotect(0x7fc18eea4000, 16384, PROT_READ) = 0
mprotect(0x60d000, 4096, PROT_READ)     = 0
mprotect(0x7fc18f0d0000, 4096, PROT_READ) = 0
munmap(0x7fc18f0a4000, 177065)          = 0
brk(NULL)                               = 0x259a000
brk(0x25bb000)                          = 0x25bb000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1669168, ...}) = 0
mmap(NULL, 1669168, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc18ef0a000
close(3)                                = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
lstat("/", {st_mode=S_IFDIR|0755, st_size=20, ...}) = 0
newfstatat(AT_FDCWD, "/home/john/.cache/google-chrome/Default/Cache", {st_mode=S_IFDIR|0700, st_size=9600, ...}, AT_SYMLINK_NOFOLLOW) = 0
openat(AT_FDCWD, "/home/john/.cache/google-chrome/Default/Cache", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = 3
fstat(3, {st_mode=S_IFDIR|0700, st_size=9600, ...}) = 0
fcntl(3, F_GETFL)                       = 0x38800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW)
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
getdents(3,

Last edited by STREBLO (2016-09-17 07:25:08)

headkase · 2016-09-17 02:23:07

What does fsck say about it?

STREBLO · 2016-09-17 02:25:46

headkase wrote:

What does fsck say about it?

I'm running ZFS. The scrub said it found no errors though.

headkase · 2016-09-17 02:28:26

STREBLO wrote:

headkase wrote:
What does fsck say about it?
I'm running ZFS. The scrub said it found no errors though.

Ah, sorry, I could use more reading comprehension as you said both in your original post.

Trilby · 2016-09-17 02:43:34

It certainly doesn't get far - the strace shows the hang on getdents, though I'm not sure where to go with that. I see google entries listing similar symptoms, but they all involve some form or additional disk - often remote - mounted below the troublesome folder.

Pardon my ignorance of ZFS, but is your ZFS pool made up of multiple physical disks? Might data under that directory be on a separate physical device from the directory or it's parents?

STREBLO · 2016-09-17 02:53:54

Trilby wrote:

It certainly doesn't get far - the strace shows the hang on getdents, though I'm not sure where to go with that. I see google entries listing similar symptoms, but they all involve some form or additional disk - often remote - mounted below the troublesome folder.
Pardon my ignorance of ZFS, but is your ZFS pool made up of multiple physical disks? Might data under that directory be on a separate physical device from the directory or it's parents?

My pool is made up of a mirror of two SSD's"

zpool status
  pool: vault
 state: ONLINE
  scan: scrub repaired 0 in 0h23m with 0 errors on Fri Sep 16 17:58:38 2016
config:

	NAME                                       STATE     READ WRITE CKSUM
	vault                                      ONLINE       0     0     0
	  mirror-0                                 ONLINE       0     0     0
	    ata-SanDisk_SDSSDXPS480G_152271401093  ONLINE       0     0     0
	    ata-SanDisk_SDSSDXPS480G_154501401266  ONLINE       0     0     0

errors: No known data errors

But no datasets live under that directory.

Last edited by STREBLO (2016-09-17 07:24:50)

STREBLO · 2016-09-17 07:23:41

Well it looks like it might be zfs related, I found a similar bug on the zfsonlinux github.

soaringowl2145 · 2016-12-17 19:37:23

In the past I have found that using a shredder works. Have you tried this method?

eric · 2017-08-07 16:25:15

I've had this kind of issues in the very early days of BtrFS. Doing rm or ls would crash the FS.
My solution then was to rename or move the directory, because the command move did not crash the FS.

WorMzy · 2017-08-07 16:42:26

I'm not sure why you felt the need to necrobump this topic with outdated information about a different filesystem, but please don't.

https://wiki.archlinux.org/index.php/Co … bumping.22

Closing.

Arch Linux

#1 2016-09-17 01:19:37

What to do with possibly corrupt, un-deletable directory

#2 2016-09-17 01:36:35

Re: What to do with possibly corrupt, un-deletable directory

#3 2016-09-17 02:02:24

Re: What to do with possibly corrupt, un-deletable directory

#4 2016-09-17 02:23:07

Re: What to do with possibly corrupt, un-deletable directory

#5 2016-09-17 02:25:46

Re: What to do with possibly corrupt, un-deletable directory

#6 2016-09-17 02:28:26

Re: What to do with possibly corrupt, un-deletable directory

#7 2016-09-17 02:43:34

Re: What to do with possibly corrupt, un-deletable directory

#8 2016-09-17 02:53:54

Re: What to do with possibly corrupt, un-deletable directory

#9 2016-09-17 07:23:41

Re: What to do with possibly corrupt, un-deletable directory

#10 2016-12-17 19:37:23

Re: What to do with possibly corrupt, un-deletable directory

#11 2017-08-07 16:25:15

Re: What to do with possibly corrupt, un-deletable directory

#12 2017-08-07 16:42:26

Re: What to do with possibly corrupt, un-deletable directory

Board footer