Date: Thu, 19 Mar 2015 12:27:05 +0200 From: Alexander Motin <mav@FreeBSD.org> To: john hood <cgull@glup.org>, freebsd-fs@FreeBSD.org Subject: Re: MMCSD erase optimization not quite right? Message-ID: <550AA479.2020404@FreeBSD.org> In-Reply-To: <550A15E6.4060903@glup.org> References: <54E80BB6.2040501@glup.org> <54F42B6B.9080307@FreeBSD.org> <550A15E6.4060903@glup.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19.03.2015 02:18, john hood wrote: > Unfortunately, this scheme of trying to expand to a single large range > and then erase it isn't very effective, at least with UFS. This isn't > the fault of the code in mmcsd. UFS doesn't issue BIO_DELETEs in a very > neat order-- it just issues them immediately when deallocating blocks. > That won't necessarily be in sequential order. I often see UFS issuing > some BIO_DELETEs within a 4MB block, and then some in another 4MB block, > which discards the first accumulated range, and then some more in the > first 4MB block. So the driver rarely actually accumulates a full 4MB > block and erases it, even if UFS is actually deleting > 4MB++. The only > situation that seems to work consistently enough to actually issue MMC > erase commands is when you delete a large file that was written with > large (1MB? 4MB?) writes on an otherwise idle system. Attached is a > diff with debugging printfs that shows this. > > This isn't the fault of the code in mmcsd, it shouldn't have to remember > multiple regions that BIO_DELETE has been issued on. Also, UFS perhaps > shouldn't issue BIO_DELETE immediately, because the block might be > reused soon (I'm not sure what the right answer here is for best flash > performance). It would be better if UFS had a kernel thread or daemon > that eventually found free regions, coalesced them into large blocks, > and BIO_DELETEd them down the stack. (fsck -E already does this, but > it's not the best place to handle this for routine operation.) > Alternately GEOM could have a BIO_DELETE manager module or > functionality, but that incurs some cost in the GEOM stack. > > I have no idea how ZFS does this, but ZFS is not very likely to be seen > on Raspberry Pis or SD cards :) ZFS actually does what you are talking about above. It accumulates list of freed blocks, aggregates them if possible, tracks reused ones, and pushes down remaining after some timeout. I don't know whether it results in many sequential 4MB chunks, but it gives as much aggregation as possible. It would be good if UFS did at least some aggregation of that kind, and I know that this topic is discussed from time to time. > Probably this issue should go out to one of the mailing lists instead of > just you and me... Probably. Done. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?550AA479.2020404>