Re: SUJ problem

On Tue, Jun 22, 2010 at 6:56 AM, Alex Keda <admin_at_lissyara.su> wrote:
> On 22.06.2010 03:26, Alexander Best wrote:
>>
>> i experienced the same problem running r209391. this might have to do
>> something with a fs being full. i saw these warnings during buildworld
>> when eventuall / ran out of space:
>>
>> Jun 21 21:32:55 otaku kernel: pid 1398 (sakura), uid 1001 inumber
>> 2661904 on /: filesystem full
>>
>
> I have 160Gb disk used as one pat for /
> Only 16% space used...

i see. so it's not an issue with / being full. maybe commit r209408
takes care of the problem. i'll update my sources and see if the
problem occurs again.

cheers.
alex

>
>
>> Jun 21 21:32:59 otaku kernel: pid 1398 (sakura), uid 1001 inumber
>> 2661904 on /: filesystem full
>> Jun 21 21:33:00 otaku kernel: pid 76033 (dd), uid 2 inumber 2591139 on
>> /: filesystem full
>> Jun 21 21:33:02 otaku kernel: pid 1398 (sakura), uid 1001 inumber
>> 2661904 on /: filesystem full
>> Jun 21 21:33:07 otaku kernel: pid 75215 (chrome), uid 1001 inumber
>> 18205737 on /: filesystem full
>> Jun 21 21:33:08 otaku kernel: pid 1467 (script), uid 1001 inumber
>> 14226185 on /: filesystem full
>> Jun 21 21:33:08 otaku kernel: pid 1398 (sakura), uid 1001 inumber
>> 2661904 on /: filesystem full
>> Jun 21 21:33:11 otaku kernel: pid 1398 (sakura), uid 1001 inumber
>> 2661904 on /: filesystem full
>> Jun 21 21:33:18 otaku kernel: pid 75215 (chrome), uid 1001 inumber
>> 18205702 on /: filesystem full
>> Jun 21 21:33:28 otaku kernel: pid 1398 (sakura), uid 1001 inumber
>> 2661461 on /: filesystem full
>> Jun 21 21:33:39 otaku kernel: pid 1398 (sakura), uid 1001 inumber
>> 2661461 on /: filesystem full
>> Jun 21 21:33:47 otaku kernel: pid 1398 (sakura), uid 1001 inumber
>> 2661904 on /: filesystem full
>> Jun 21 21:33:48 otaku kernel: pid 75215 (chrome), uid 1001 inumber
>> 16086093 on /: filesystem full
>> Jun 21 21:33:50 otaku kernel: pid 1398 (sakura), uid 1001 inumber
>> 2661461 on /: filesystem full
>>
>> followed by lots of
>>
>> Jun 21 21:35:25 otaku kernel: bad block 7020785329444114652, ino 7468267
>> Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber
>> 7468267 on /: bad block
>> Jun 21 21:35:25 otaku kernel: bad block -315669439672768816, ino 7468267
>> Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber
>> 7468267 on /: bad block
>> Jun 21 21:35:25 otaku kernel: bad block -3220207053503867546, ino 7468267
>> Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber
>> 7468267 on /: bad block
>> Jun 21 21:35:25 otaku kernel: bad block -6419917778393221405, ino 7468267
>> Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber
>> 7468267 on /: bad block
>> Jun 21 21:35:25 otaku kernel: bad block 3919397040058727880, ino 7468267
>> Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber
>> 7468267 on /: bad block
>> Jun 21 21:35:25 otaku kernel: bad block -6888424595660707789, ino 7468267
>> Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber
>> 7468267 on /: bad block
>> Jun 21 21:35:25 otaku kernel:
>> g_vfs_done():ufs/rootfs[READ(offset=100240429127958528,
>> length=16384)]error = 5
>> Jun 21 21:35:25 otaku kernel: bad block -1173790944229704887, ino 7468267
>> Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber
>> 7468267 on /: bad block
>> Jun 21 21:35:25 otaku kernel: bad block 5537349803492323867, ino 7468267
>> Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber
>> 7468267 on /: bad block
>> Jun 21 21:35:25 otaku kernel: bad block 882554538064816358, ino 7468267
>> Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber
>> 7468267 on /: bad block
>> Jun 21 21:35:25 otaku kernel: bad block -2565060229441336925, ino 7468267
>>
>> ~ 2 minutes later (see timestamp). i then did a `find / -inum 7468267`
>> but couldn't find the file. i then did a clean reboot using `shutdown
>> -r now`. the buffers got synched down to 0 however it said something
>> like "/ cannot be unmounted filesystem busy".
>>
>> i then was thrown into single user mode due to the same problem alex
>> kada reported. at some point i did a `mount -f /` and did `dmesg -a>
>> /FEHLER`. strange thing is that everything seems to have been piped to
>> that file twice. after that i did `fastboot` and freebsd came up with
>> / being clean (although the last fsck report said / was marked dirty).
>> i've attached the file.
>>
>> cheers.
>>
>>
>
>



-- 
Alexander Best