Hi all,
I'm not a subscriber to this list (so please put me in the CC), but I've
hit a really annoying un-googleable issue that I don't know who to ask
about.
A runaway script has been recursively creating sub-directories under
sub-directories until it hit the (apparent) OS limit. The path in
question goes something like this:
/work/build-native/binutils-gdb/gnulib/confdir3/confdir3/confdir3/confdir3/confdir3/........
(you get the idea)
It was only stopped by the following error:
mkdir: cannot create directory 'confdir3': File name too long
OK, fine, that was silly but whatever, right? I tried to delete this
huge directory from the top with
rm -rf confdir3/
but that simply generated the same error as above. So, I figured "Hey,
I'll just walk all the way to the bottom, and delete the directories
one-by-one bottom up". Here's the script I ran to get to the bottom:
$ for i in $(seq 999999); do echo "im $i levels deep"; cd confdir3; done;
It then ran for a while, and eventually I got to the bottom:
```
...
im 892 levels deep
im 893 levels deep
im 894 levels deep
im 895 levels deep
im 896 levels deep
bash: cd: confdir3: File name too long
$ ls
<nothing here>
```
So then, I `cd ../`, and `rmdir confdir3`, but even here, I get
rmdir: failed to remove 'confdir3/': File name too long
I would be very grateful if someone could please help suggest how I
might get this infernal tower of directories off of my precious ext4
partition.
I was thinking maybe there's some kind of magic "forget this directory
inode ever existed" command, but I am out of my depth with filesystems.
Best Regards,
Maxim Blinov
I forgot to mention in the first email: I'm running Ubuntu 20.04 in a
RISC-V QEMU image, so it's not exactly your standard setup.
I've also made an interesting observation. If I descend to the very
bottom of the directory tree, I can trigger the following behaviour:
```
$ mkdir b
$ ls
a b
$ rmdir b
rmdir: failed to remove 'b': File name too long
```
(the file 'a' was created from an earlier experiment.)
cc'ing linux-fsdevel too.
On 22/01/27 07:06AM, Maxim Blinov wrote:
> Hi all,
>
> I'm not a subscriber to this list (so please put me in the CC), but I've
> hit a really annoying un-googleable issue that I don't know who to ask
> about.
>
> A runaway script has been recursively creating sub-directories under
> sub-directories until it hit the (apparent) OS limit. The path in
> question goes something like this:
>
> /work/build-native/binutils-gdb/gnulib/confdir3/confdir3/confdir3/confdir3/confdir3/........
> (you get the idea)
>
> It was only stopped by the following error:
> mkdir: cannot create directory 'confdir3': File name too long
>
> OK, fine, that was silly but whatever, right? I tried to delete this
> huge directory from the top with
;)
>
> rm -rf confdir3/
>
> but that simply generated the same error as above. So, I figured "Hey,
Strange. Though I didn't try creating same name subdirectories like how you have
done above i.e. confdir3 within confdir3 and recurse.
But I was able to remove the parent directory after hitting the max PATH_LEN
issue.
I ran this test below test to see if it fails on my ext4 latest tree. But this
passes. https://github.com/pjd/pjdfstest/blob/master/tests/mkdir/03.t
But just curious, by any chance did below fixes it for you?
echo 3 > /proc/sys/vm/drop_caches
-ritesh
> I'll just walk all the way to the bottom, and delete the directories
> one-by-one bottom up". Here's the script I ran to get to the bottom:
>
> $ for i in $(seq 999999); do echo "im $i levels deep"; cd confdir3; done;
>
> It then ran for a while, and eventually I got to the bottom:
>
> ```
> ...
> im 892 levels deep
> im 893 levels deep
> im 894 levels deep
> im 895 levels deep
> im 896 levels deep
> bash: cd: confdir3: File name too long
> $ ls
> <nothing here>
> ```
>
> So then, I `cd ../`, and `rmdir confdir3`, but even here, I get
>
> rmdir: failed to remove 'confdir3/': File name too long
>
> I would be very grateful if someone could please help suggest how I
> might get this infernal tower of directories off of my precious ext4
> partition.
>
> I was thinking maybe there's some kind of magic "forget this directory
> inode ever existed" command, but I am out of my depth with filesystems.
>
> Best Regards,
>
> Maxim Blinov
On Thu, Jan 27, 2022 at 05:50:39PM +0530, Ritesh Harjani wrote:
> On 22/01/27 07:06AM, Maxim Blinov wrote:
> > $ for i in $(seq 999999); do echo "im $i levels deep"; cd confdir3; done;
> >
> > It then ran for a while, and eventually I got to the bottom:
> >
> > ```
> > ...
> > im 892 levels deep
> > im 893 levels deep
> > im 894 levels deep
> > im 895 levels deep
> > im 896 levels deep
> > bash: cd: confdir3: File name too long
> > $ ls
> > <nothing here>
> > ```
> >
> > So then, I `cd ../`, and `rmdir confdir3`, but even here, I get
> >
> > rmdir: failed to remove 'confdir3/': File name too long
> >
> > I would be very grateful if someone could please help suggest how I
> > might get this infernal tower of directories off of my precious ext4
> > partition.
> >
> > I was thinking maybe there's some kind of magic "forget this directory
> > inode ever existed" command, but I am out of my depth with filesystems.
here's an idea:
while true; do
mv confdir3/confdir3 tmpd; rmdir confdir3; mv tmpd confdir3;
done
Hi Matthew, Ritesh,
On 27/01/2022 13:40, Matthew Wilcox wrote:
> here's an idea:
>
> while true; do
> mv confdir3/confdir3 tmpd; rmdir confdir3; mv tmpd confdir3;
> done
>
Thankyou for all your comments - mv'ing a child directory "up" and
deleting *that* did the trick!
Infact I was complaining about this to some colleagues who kindly
pointed me to this thread [1] where someone has exactly the same issue.
Searching for `confdir3`, it turns out this issue is more googleable
than I initially realized - there's quite a few others who have bumped
into these weird path length limitations, in particular with docker
(there's another thing I forgot to mention - to be clear, I'm running
QEMU inside a docker container.)
Still it seems strange, since the QEMU VM disk image is a static file
within the docker file system, and there are no bind mounts going on in
the container.
[1]: https://github.com/moby/moby/issues/13451
...Oh dear, I think I may have been extremely stupid: This entire time I
thought I was typing into the QEMU VM, but in actual fact I was typing
into the docker container that contained it.
So this wasn't an ext4 issue at all, but a limitation of whatever
filesystem docker containers use.