Bug 19162

Summary: 4.0-STABLE panics w/ softupdates and quota when user goes over inode limit
Product: Base System Reporter: lgodsey <lgodsey>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.0-STABLE   
Hardware: Any   
OS: Any   

Description lgodsey 2000-06-10 00:20:00 UTC
With softupdates and quota enabled, any user going over their inode limit will cause a kernel panic

Fix: 

unknown.
How-To-Repeat: enable softupdates & quota in kernel, set a user on /home to have X # inode limit, su user, and touch a few files till the user is over inode limit.. PANIC!
Comment 1 Jeroen Ruigrok van der Werven freebsd_committer freebsd_triage 2000-06-11 11:23:12 UTC
State Changed
From-To: open->analyzed

I informed Kirk McKusick about this PR and he is investigating this.
Comment 2 Jeroen Ruigrok van der Werven freebsd_committer freebsd_triage 2000-06-21 06:18:41 UTC
State Changed
From-To: analyzed->feedback

Mr McKusick commited a fix a few days ago, could you test this and verify 
if it works for your situation? 


Comment 3 Jeroen Ruigrok van der Werven freebsd_committer freebsd_triage 2000-06-21 06:18:41 UTC
Responsible Changed
From-To: freebsd-bugs->asmodai

I'm monitoring/working on this with Kirk.  So I'll keep close tabs.
Comment 4 sdehaan 2000-09-14 07:14:50 UTC
Hi ,

It seems that there is stil a problem in handling inode quota's on FreeBSD stable 4.1
I have a mailserver with a /home filesystem where the homedirectory's of the users are. 
I use the latest 4.1 stable sources.

I wanted some quota's on the max size of the mailbox and the max number of files used (its maildir format so thats the number of emails) by a user.

There is no problem when the max size is exceeded. The system returns the email with a 'Quota exceeded' warning. However when some user exceeds the max number of inodes, the system panic's

I tried also to create a file as a user and than the system also panics as described.

As a second test i tried it without softupdates on the /home partition. Than the  system works as it should be. 

It seems that there is a problem in using softupdates and inode quota's. 
Hopefully this will help solve the problem.


Kindly regards,


Koos de Haan


Mount :

/dev/da0s1a on / (ufs, local, soft-updates)
/dev/da0s1e on /usr (ufs, local, soft-updates)
/dev/da0s1f on /usr/local (ufs, local, soft-updates)
/dev/da0s1g on /home (ufs, local, with quotas, soft-updates)
procfs on /proc (procfs, local)
mfs:30 on /tmp (mfs, asynchronous, local, nodev, nosuid)
/dev/da1s1e on /var (ufs, local, soft-updates)
/dev/da1s1f on /var/spool/postfix (ufs, local, soft-updates)



Panic :

panic: worklist_remove: not in list
Debugger("panic")
db> trace
Debugger(c02ad623) at Debugger+0x34
panic(c02c2edf,e1cbdc4c,c024330d,c2d90180,c2d87300) at panic+0x70
worklist_remove(c2d90180) at worklist_remove+0x2d
check_inode_unwritten(c2d90180) at check_inode_unwritten+0x61
softdep_freefile(e1cc1680,2741d04,8180,45,e1cbddb0)at softdep_freefile+0x6f
ffs_vfree(e1cc1680,2741d04,8180,e1cbde00,e1cbde14) at ffs_vfree+0x28
ufs_makeinode(8180,e1cc1740,e1cbdee0,e1cbdef4) at ufs_makeinode+0xd7
ufs_create(e1cbde00,e1cbde74,c01900c8,e1cbde00,0) at ufs_create+0x28
ufs_vnoperate(e1cbde00,0,e1cbdf80,c2d8dd00,e1c98f60) at ufs_vnoperate+0x15
vn_open(e1cbdecc,a02,180,e1c98f60,3) at vn_open+0x10c
open(e1c98f60,e1cbdf80,a01,8075708,8073c08) at open+0xb5
syscall2(2f,2f,2f,8073c08,8075708) at syscall2+0x1f1
Xint0x80_syscall() at Xint0x80_syscall+0x25
db>
 
-
--

Kabelfoon BV
Industriestraat 30, Postbus 45, 2670 AA  NAALDWIJK
Telefoon: 0174-615430 Fax: 0174-623860
Helpdesk: 0900-5224357 (44ct/min)
Abonnementen: 0800-5223666
e-mail info@kabelfoon.nl voor informatie, kabelfoon@kabelfoon.nl voor abonnementszaken, help@kabelfoon.nl voor de helpdesk
Homepage : http://www.kabelfoon.nl/
Comment 5 Jeroen Ruigrok van der Werven freebsd_committer freebsd_triage 2001-06-20 14:10:20 UTC
Responsible Changed
From-To: asmodai->freebsd-bugs

I don't have the time currently to chase this up further. 
Any filesystem people who want to tackle this?
Comment 6 Sheldon Hearn freebsd_committer freebsd_triage 2002-01-17 16:12:05 UTC
State Changed
From-To: feedback->closed

Automatic feedback timeout.  If additional feedback that warrants 
the re-opening of this PR is available but not included in the 
audit trail, please include the feedback in a reply to this message 
(preserving the Subject line) and ask that the PR be re-opened.