On 03/30/10 01:25 PM, Nicolas Williams wrote: > On Tue, Mar 30, 2010 at 12:42:00PM -0600, Tim Haley wrote: >> On 03/30/10 12:29 PM, Dan Price wrote: >>> The example was slightly messed up, sorry; that caused misunderstanding. >>> I'm worried about this situation: >>> >>> snapshot at 1 >>> mv /myfiles/name1 /myfiles/name2 >>> mkdir /myfiles/name1 >>> snapshot at 2 >>> >>> So, I'm fairly sure that between the two snapshots both events are >>> relevant. So the above might yield: >>> >>> + /myfiles/name1 >>> R /myfiles/name1 -> /myfiles/name2 > > Ah, sure. > >> Apologies for not responding sooner, I've been playing a bit with >> the code. Based on what I've been doing this morning, I believe it >> will be possible to present the list in roughly chronological order. >> The order originally was just by object number, so you could get >> either of the outputs you show above. > > If you include the object number in the output then you can let the > consumer figure it out. Increasing zfs diff's footprint to get it to > sort its output correctly will decrease its performance, and the > consumer might not care. (OTOH, a light-weight algorithm for properly > sorting these output lines is fairly obvious, so maybe there's no reason > to be concerned about performance.) > > Nico
It would be easy enough for me to print a 'time' column as the first column, and the output could then be sent to 'sort -n'. I'm not sure how people feel about that. Is that cheating? :-) The alternative is to AVL sort by that time, which as you note will increase the footprint, perhaps dramatically for a really big diff. -tim
