From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 24 Oct 2018 12:51:16 +0300 From: Vladimir Davydov Subject: Re: [PATCH v2 4/4] wal: delete old wal files when running out of disk space Message-ID: <20181024095116.ldsc3j2dn4kmzsjy@esperanza> References: <20181023184645.GC29694@chai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181023184645.GC29694@chai> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Tue, Oct 23, 2018 at 09:46:45PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [18/10/23 20:30]: > > +static void > > +gc_process_wal_event(struct wal_watcher_msg *msg) > > +{ > > + if ((msg->events & WAL_EVENT_GC) == 0) > > + return; > > GC is now subscribed to all events only to react to those *gc* > events which delete wal files in case of emergency. > > Shouldn't gc ignore wal gc events which were initiated by > wal_collect_garbage() at least? > Why send wal_event_gc for these events? Well, we could pass a mask of events a subscriber is interested in. Come to think of it, this would look better IMO. > > wal watcher api is an artefact from the times when we had no > cbus connection between wal and tx. No, this isn't true. WAL watcher was introduced as a generic notification channel built over cbus in the first place. Before it was made available, we used inotify to track WAL directory changes in relays. > Now you can send a direct message to gc. Why use wal watcher api at > all? Because we already have a generic abstraction, and I think we'd better use it instead of adding another wal-tx pipe to the wal_thread and implementing home-brewed notifications on top of it.