On 26/11/10 20:55, 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_.
Abusing the Netlink protocol to overcome the "supposed to be" limitation
does not seem to me the way to go. Moreover, if we ever have more than X
bytes rule-sets (I don't remember that limit that you have previously
mentioned), you'll have to add some locking strategy anyway.
The locking is the way to go.
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. :-/
He will notice that he did that because he hits EAGAIN, so he can kill
the process in background and retry.
--
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
