On Mon, Aug 20, 2012 at 10:21:37PM -0400, Neal Murphy wrote: > On Monday 20 August 2012 20:30:26 /dev/rob0 wrote: > > The main benefit is that iptables-restore is atomic. All changes > > are committed in one pass. Any error in the ruleset means your > > existing ruleset is not replaced. > > [Minor digression] > By 'atomic', do you mean that all of the changes are made with a > single COMMIT, regardless of how many tables are accessed and > regardless of how many rules are processed? I don't know. I was hoping that someone familiar with the source would answer. > It's been my experience that there is an implicit COMMIT at every > table change, and there is a ballpark limit of around 20,000 rules > per commit. Thus: > - if the file you are feeding to iptables-restore references one > table only and contains fewer than around 20,000 rules, the > operation will be atomic. > - if the file you are feeding to iptables-restore references more > than one table and contains fewer than around 20,000 rules per > table, then only the changes *per table* will be atomic. > - If the changes to a table contain more than around 20,000 rules, > then that operation will require more than one COMMIT and will > NOT be atomic. > > When relatively small change sets are involved, I agree that > iptables-restore is atomic. But when very large change sets are > involved, I disagree: iptables-restore is *not* necessarily > atomic. To be pedantic, it would be correct to say that > iptables-restore operates atomically only under certain > conditions. Interesting, thanks. I think my post was right in the usual case, however, and that your examples of >20K rules might be better handled by ipset(8). -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
