search for: ext3_setattr

...e appears to be a bug w.r.t. chown and quotas in ext3. In particular, if you "chown" a file on a filesystem with userquotas enabled, the quota charge in not transfered. ditto "chgrp" and group quotas. This happens because i_op->setattr has been redefined for files, and ext3_setattr doesn't do the DQUOT_TRANSFER like it should. I have fixed it by adding a stanza like: if ((attr->ia_valid & ATTR_UID && attr->ia_uid != inode->i_uid) || (attr->ia_valid & ATTR_GID && attr->ia_gid != inode->i_gid)) error = DQUOT_TRANSFER(inod...

...3>] ext3_reserve_inode_write+0x33/0x89 [<c016aac1>] ext3_mark_inode_dirty+0x18/0x31 [<c017082b>] journal_start+0x7f/0xa9 [<c016ab26>] ext3_dirty_inode+0x4c/0x5f [<c0156c20>] __mark_inode_dirty+0x24/0xce [<c01527d2>] inode_setattr+0x118/0x123 [<c016a951>] ext3_setattr+0xc9/0x104 [<c0152903>] notify_change+0xda/0x143 [<c013c6b9>] sys_utime+0xec/0x110 [<c013e5ad>] __fput+0xc2/0xde [<c013d251>] filp_close+0x5a/0x63 [<c013d2b2>] sys_close+0x58/0x7a [<c0108807>] syscall_call+0x7/0xb Code: 0f 0b 8f 06 52 3d 22 c0 83 c4 14 85...

...f20 ffffffff 00000000 c0344cff c01179c9 c0344900 00000400 c02733da cdb21e4c 00000000 c02725c6 d11e0a00 d201ab60 c01672a8 c02733c0 00000118 c02725c6 cdb21e6c 00000000 Call Trace: [<c01179c9>] printk+0x61/0x114 [<c01672a8>] __ext3_std_error+0x30/0x40 [<c0162c0a>] ext3_setattr+0x19a/0x1b0 [<c014b606>] notify_change+0xe6/0x180 [<c013696b>] do_truncate+0x5b/0x78 [<c0142d41>] may_open+0x165/0x17c [<c0143015>] open_namei+0x2bd/0x3d0 [<c013770f>] filp_open+0x3b/0x5c [<c0137a63>] sys_open+0x37/0x78 [<c0108877>] syscall_call+0x7/...

...bd:journal_invalidatepage+0xdc/0x358 [<ffffffff8021d3dd>] truncate_complete_page+0x1b/0x5c [<ffffffff8022b98f>] truncate_inode_pages_range+0x9b/0x290 [<ffffffff802c555b>] vmtruncate+0x4e/0xc9 [<ffffffff8024335e>] inode_setattr+0x22/0x104 [<ffffffff88050b2f>] :ext3:ext3_setattr+0x1bd/0x228 [<ffffffff8022ceab>] notify_change+0x145/0x2f3 [<ffffffff802d17af>] do_truncate+0x5e/0x79 [<ffffffff80212f1a>] may_open+0x1d3/0x22f [<ffffffff8021b4ce>] open_namei+0x2c8/0x6ed [<ffffffff80227a14>] do_filp_open+0x1c/0x38 [<ffffffff8021a1b8>] do_s...

...Trace: [<c0127061>] truncate_list_pages [kernel] 0x79 18:03:10 kernel: [<c01271ff>] truncate_inode_pages [kernel] 0x3b 18:03:10 kernel: [<c0124f2e>] vmtruncate [kernel] 0x96 18:03:10 kernel: [<c01491f0>] inode_setattr [kernel] 0x24 18:03:10 kernel: [<d401f963>] ext3_setattr [ext3] 0x1c3 18:03:10 kernel: [<d401d810>] ext3_get_block [ext3] 0x0 18:03:10 kernel: [<c01281db>] do_generic_file_read [kernel] 0x2c3 18:03:10 kernel: [<c0149359>] notify_change [kernel] 0x5d 18:03:10 kernel: [<c012a2aa>] generic_file_write [kernel] 0x5c2 18:03:10...

...8> Trace; c007e2d8 <journal_revoke+40/358> Trace; c006be04 <ext3_forget+f4/184> Trace; c006ed18 <ext3_free_branches+11c/288> Trace; c006f1c0 <ext3_truncate+33c/4c0> Trace; c0025424 <vmtruncate+148/160> Trace; c00589ac <inode_setattr+34/108> Trace; c00701c8 <ext3_setattr+144/190> Trace; c0058bc4 <notify_change+90/13c> Trace; c00398dc <do_truncate+108/1cc> Trace; c004be94 <open_namei+650/7e8> Trace; c003ad70 <filp_open+58/84> Trace; c003b25c <sys_open+4c/fc> Trace; c0003dfc <ret_from_syscall_1+0/b4> Trace; 01819404 Before first...

...Trace: [<c0127061>] truncate_list_pages [kernel] 0x79 18:03:10 kernel: [<c01271ff>] truncate_inode_pages [kernel] 0x3b 18:03:10 kernel: [<c0124f2e>] vmtruncate [kernel] 0x96 18:03:10 kernel: [<c01491f0>] inode_setattr [kernel] 0x24 18:03:10 kernel: [<d401f963>] ext3_setattr [ext3] 0x1c3 18:03:10 kernel: [<d401d810>] ext3_get_block [ext3] 0x0 18:03:10 kernel: [<c01281db>] do_generic_file_read [kernel] 0x2c3 18:03:10 kernel: [<c0149359>] notify_change [kernel] 0x5d 18:03:10 kernel: [<c012a2aa>] generic_file_write [kernel] 0x5c2 18:03:10...

...EXT3-fs error (device sd(8,51)) in ext3_new_inode: IO failure Dec 24 13:48:37 10.17.0.2 kernel: SCSI disk error : host 3 channel 0 id 0 lun 1 return code = 10000 Dec 24 13:48:37 10.17.0.2 kernel: I/O error: dev 08:33, sector 0 Dec 24 13:48:37 10.17.0.2 kernel: EXT3-fs error (device sd(8,51)) in ext3_setattr: IO failure Dec 24 13:48:38 10.17.0.2 kernel: SCSI disk error : host 3 channel 0 id 0 lun 1 return code = 10000 Dec 24 13:48:38 10.17.0.2 kernel: I/O error: dev 08:33, sector 0 Dec 24 13:48:38 10.17.0.2 kernel: Assertion failure in do_get_write_access() at transaction.c:737: "(((jh2bh(jh)...

...<[ext3]start_transaction+94/a0> Trace; f88c3858 <[ext3]ext3_truncate+d8/480> Trace; c020c28c <skb_copy_datagram_iovec+4c/690> Trace; c0209fe1 <alloc_skb+361/370> Trace; c012c063 <vmtruncate+d3/9e0> Trace; c0159c76 <inode_setattr+106/190> Trace; f88c473c <[ext3]ext3_setattr+25c/320> Trace; c024601e <inet_recvmsg_R__ver_inet_recvmsg+4e/70> Trace; c0159fce <notify_change+2ce/350> Trace; c013e2e6 <fd_install+b6/b70> Trace; c0148bb3 <cdput+8c3/bb0> Trace; c013f98d <generic_file_open+55d/650> Trace; c013e397 <fd_install+167/b70> Trace...

I got this.. The system was usuable, but not very. If I tried to access the ext3 volume, it would hang. Reboot hung too, complaining about too many open files. Any ideas? I have no idea what triggered it; this is a big file/web/mail server, with all of that on the ext3 volume. And I've never run ksymoops before, but I think I did it right. - Josh Assertion failure in

i_alloc_sem has always been a bit of an odd "lock". It''s the only remaining rw_semaphore that can be released by a different thread than the one that locked it, and it''s use case in the core direct I/O code is more like a counter given that the writers already have external serialization. This series removes it in favour of a simpler counter scheme, thus getting rid