On Fri, 26 Nov 2010, Jan Engelhardt wrote: > On Friday 2010-11-26 20:48, Jozsef Kadlecsik wrote: > >> > > >> >What is that initial data handling in dumps for? > >> > >> Making an atomic snapshot/copy of the table. A userspace client > >> could take almost indefinitely on retrieving a table, so it is > >> possible that something else changes tables meanwhile. > > > >Why don't you lock the tables during dumping? That way the tables won't > >change, whatever long time the dump takes. Snapshotting the table looks as > >wasting memory and time. > > For that to work, I would have to use a locking primitive that can be > held across returns to userspace, which leaves semaphores as the only > option and, ya, I didn't quite feel like using _that_. Also sounds a > bit like a killer if an admin cannot update a table just because he > forgot some dumper process in the background in suspended state. :-/ There's already an internal mutex there (cb_mutex), to serialize dumping. (It's unfortunate that cb_mutex cannot be accessed, for other purposes.) And the kernel->userspace messaging is asynchronous, so I think suspended dumping process won't hurt: the messages will wait it the queue, that's all. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
