Date: Sat, 29 Mar 2014 01:52:17 +0400 (MSK) From: Dmitry Morozovsky <marck@rinet.ru> To: Freddie Cash <fjwcash@gmail.com> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: zfs l2arc warmup Message-ID: <alpine.BSF.2.00.1403290146310.60856@woozle.rinet.ru> In-Reply-To: <CAOjFWZ5F7O%2Bje9w=agwLTu0Jm2-PfzjasEBYQEqD%2B%2B5LvTE_FQ@mail.gmail.com> References: <CAFfb-hpi20062%2BHCrSVhey1hVk9TAcOZAWgHSAP93RSov3sx4A@mail.gmail.com> <CALfReydi_29L5tVe1P-aiFnm_0T4JJt72Z1zKouuj8cjHLKhnw@mail.gmail.com> <CAFfb-hpZos5-d3xo8snU1aVER5u=dSFRx-B-oqjFRTkT83w0Kg@mail.gmail.com> <20140328005911.GA30665@neutralgood.org> <CAFfb-hr=wR6nxqL%2B4tn-y2eQEw4n_g7rZoK9rRLnm_Ldcm1TZQ@mail.gmail.com> <alpine.BSF.2.00.1403290032070.60856@woozle.rinet.ru> <CAOjFWZ7h5080%2BzEvSfzxgENwP%2BPXEXKPXdEDHAtbx5RAxxWT0g@mail.gmail.com> <alpine.BSF.2.00.1403290116550.60856@woozle.rinet.ru> <CAOjFWZ5F7O%2Bje9w=agwLTu0Jm2-PfzjasEBYQEqD%2B%2B5LvTE_FQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 28 Mar 2014, Freddie Cash wrote: > > I'm thinking not about losing the transaction, but possibly putting your > > filesystem in the middle of (database PoV) transaction, hence render your > > DB > > inconsistent? > > > > Quick googling seems to be uncertain about it... > > > > ?That I don't know. Again, I'm not a ZFS code guru; just a very > happy/active ZFS user and reader of stuff online. :) > > You're thinking of the small window where: > - database writes transaction to disk > - zfs writes ?the data to the ZIL on the log vdev > - zfs returns "data is written to disk" to the DB > - zfs queues up the write to the pool > - the log device dies > - the pool is forcibly exported/server loses power Pretty much the same I'm just written in the parallel reply ;) > Such that the DB considers the transaction complete and the data safely > written to disk, but it's actually only written to the ZIL on the separate > log device (which no longer exists) and is not stored in the pool yet. So, if ZIL dies but server is alive the sync write will be done, IIUC from your and other's comments? Then, of course, it will shorten the width of dangerous to nearly zero. > Yeah, that could be a problem. A very unlikely event, although not > entirely impossible. > > ?I would think it would be up to the database to be able to roll-back a > database to prior to the corrupted transaction. If the DB has a log or > journal or whatever, then it could be used to roll-back, no? If it could detect this situation, yes. I'm not sure detecting this while getting (previously) state like "write has been done" couldbe simple though ;P > It's still considered best practice to use mirror log device. It's just no > longer required, nor does a dead log lead to a completely dead pool.? Well, I suppose the middle point is like "weight your abilities to lose data, and prepare measures" ;P For the database case, I'm not so sure, alas. But, anyway, thank you very much for thougthful comments! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1403290146310.60856>