ext2 filesystem made full, space not released by delete

[Quozl]

A sequence of tests resulted in a full ext2 filesystem with q4d09ja.

ok del int:\ok.bmp t-sec( copy http:\\qz\ok.bmp int:\ )t-sec dir int:\ok.bmp
29s ext2-file-system
----rw-rw-rw-   3240138  2012-04-19 01:57:39  ok.bmp
ok del int:\ok.bmp t-sec( copy http:\\qz\ok.bmp int:\ )t-sec dir int:\ok.bmp
26s ext2-file-system
----rw-rw-rw-   3240138  2012-04-19 01:58:12  ok.bmp
ok del int:\ok.bmp t-sec( copy http:\\qz\ok.bmp int:\ )t-sec dir int:\ok.bmp
18s ext2-file-system
----rw-rw-rw-   3240138  2012-04-19 01:58:57  ok.bmp
ok del int:\ok.bmp t-sec( copy http:\\qz\ok.bmp int:\ )t-sec dir int:\ok.bmp
17s ext2-file-system
----rw-rw-rw-   3240138  2012-04-19 02:12:35  ok.bmp
ok del int:\ok.bmp t-sec( copy http:\\qz\ok.bmp int:\ )t-sec dir int:\ok.bmp
18s ext2-file-system
----rw-rw-rw-   3240138  2012-04-19 02:17:14  ok.bmp
ok del int:\ok.bmp t-sec( copy http:\\qz\ok.bmp int:\ )t-sec dir int:\ok.bmp
18s ext2-file-system
----rw-rw-rw-   3240138  2012-04-19 02:17:48  ok.bmp
ok del int:\ok.bmp t-sec( copy http:\\qz\ok.bmp int:\ )t-sec dir int:\ok.bmp
19s ext2-file-system
----rw-rw-rw-   3240138  2012-04-19 02:18:30  ok.bmp
ok del int:\ok.bmp t-sec( copy http:\\qz\ok.bmp int:\ )t-sec dir int:\ok.bmp
18s ext2-file-system
----rw-rw-rw-   3240138  2012-04-19 02:19:55  ok.bmp
ok del int:\ok.bmp t-sec( copy http:\\qz\ok.bmp int:\ )t-sec dir int:\ok.bmp
17s ext2-file-system
----rw-rw-rw-   3240138  2012-04-19 02:20:57  ok.bmp
ok del int:\s2 t-sec( copy http:\\qz\s2 int:\ )t-sec dir int:\s2
56s ext2-file-system
----rw-rw-rw-  11491345  2012-04-19 02:22:45  s2
ok del int:\s2 t-sec( copy http:\\qz\s2 int:\ )t-sec dir int:\s2
no free blocks found
45s ext2-file-system
----rw-rw-rw-   8961024  2012-04-19 02:27:34  s2
ok 

[Quozl]

e2fsck -f yielded

bash-4.2# e2fsck -f /dev/mmcblk0p1
e2fsck 1.42 (29-Nov-2011)
Pass 1: Checking inodes, blocks, and sizes
Inode 24, i_blocks is 17730, should be 17572.  Fix<y>? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Unattached inode 14
Connect to /lost+found<y>? yes

Inode 14 ref count is 2, should be 1.  Fix<y>? yes

Unattached inode 15
Connect to /lost+found<y>? yes

Inode 15 ref count is 2, should be 1.  Fix<y>? yes

Unattached inode 16
Connect to /lost+found<y>? yes

Inode 16 ref count is 2, should be 1.  Fix<y>? yes

Unattached inode 17
Connect to /lost+found<y>? yes

Inode 17 ref count is 2, should be 1.  Fix<y>? yes

Unattached inode 18
Connect to /lost+found<y>? yes

Inode 18 ref count is 2, should be 1.  Fix<y>? yes

Unattached inode 19
Connect to /lost+found<y>? yes

Inode 19 ref count is 2, should be 1.  Fix<y>? yes

Unattached inode 20
Connect to /lost+found<y>? yes

Inode 20 ref count is 2, should be 1.  Fix<y>? yes

Unattached inode 21
Connect to /lost+found<y>? yes

Inode 21 ref count is 2, should be 1.  Fix<y>? yes

Unattached inode 23
Connect to /lost+found<y>? yes

Inode 23 ref count is 2, should be 1.  Fix<y>? yes

Pass 5: Checking group summary information

Boot: ***** FILE SYSTEM WAS MODIFIED *****
Boot: 78/16384 files (11.5% non-contiguous), 65536/65536 blocks

Workaround: the files could then be deleted from lost+found and the space freed.

[Quozl]

The symptom is caused by direct-unlink skipping idelete, in turn because +link-count does not decrement the link count. This was added in svn 2817.

Minimal reproducer:

ok " int:\test" r/w open-file drop close-file

How to detect the damage and clean the filesystem:

umount -a
e2fsck -f /dev/mmcblk0p1

A workaround:

dev /packages/ext2-file-system
: +link-count'
   dir? link-count 1 = and  if  drop exit  then
   link-count +  dup d# 65000 >=  if  drop 1  then 
   link-count!
;
patch +link-count' +link-count dirent-unlink
patch +link-count' +link-count fill-dirent

[wmb@…]

I think the general approach outlined in the workaround is correct. svn 2946 implements that approach with slightly more explicit code.

[Quozl]

Tested svn 2946 in a local build. Fixes this symptom.

[Quozl]

Is in Q4D11.