Date: Sat, 17 Nov 2012 21:15:20 -0500 From: Zaphod Beeblebrox <zbeeble@gmail.com> To: Adam McDougall <mcdouga9@egr.msu.edu> Cc: freebsd-fs@freebsd.org Subject: Re: SSD recommendations for ZFS cache/log Message-ID: <CACpH0MeuAY=-1HdqOUnm3nJF_fTrqLycX-XZZw%2BM3xxoy1%2Bk-g@mail.gmail.com> In-Reply-To: <20121117225851.GJ1462@egr.msu.edu> References: <CAFHbX1K-NPuAy5tW0N8=sJD=CU0Q1Pm3ZDkVkE%2BdjpCsD1U8_Q@mail.gmail.com> <57ac1f$gf3rkl@ipmail05.adl6.internode.on.net> <50A31D48.3000700@shatow.net> <CAF6rxgkh6C0LKXOZa264yZcA3AvQdw7zVAzWKpytfh0%2BKnLOJg@mail.gmail.com> <20121116044055.GA47859@neutralgood.org> <CACpH0MfQWokFZkh58qm%2B2_tLeSby9BWEuGjkH15Nu3%2BS1%2Bp3SQ@mail.gmail.com> <50A64694.5030001@egr.msu.edu> <20121117181803.GA26421@neutralgood.org> <20121117225851.GJ1462@egr.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 17, 2012 at 5:58 PM, Adam McDougall <mcdouga9@egr.msu.edu> wrote: > Some found a way to measure progress and kept letting it churn/deadlock/reboot > until things came back to normal. I think in -current there is a new zfs > feature allowing for background deletion that may ease this issue, and > someone reported success. I think the "feature" you're thinking about is the background deletion of a filesystem object. As I recall the problem, the deletion of a filesystem object is atomic ... and can hang a whole array while it happens (I suppose this is doubly true if the filesystem is deduped). The patch makes this happen in the background. However... it wouldn't have any effect on removing a non-filesystem chuck of data, AFAIK. In my experience of copying 1T of data and then recopying that same 1T of data, the first copy took some hours and the 2nd copy took some days. The first delete took many days and the 2nd delete was fairly quick.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACpH0MeuAY=-1HdqOUnm3nJF_fTrqLycX-XZZw%2BM3xxoy1%2Bk-g>