Date: Thu, 6 Sep 2018 16:34:42 -0700 From: Mark Millard <marklmi@yahoo.com> To: Kirk McKusick <mckusick@mckusick.com> Cc: bob prohaska <fbsd@www.zefox.net>, FreeBSD Filesystems <freebsd-fs@FreeBSD.org> Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems Message-ID: <B9914A0D-69DC-4D3F-9BA4-D180462B2FA5@yahoo.com> In-Reply-To: <201809062330.w86NUphJ027262@chez.mckusick.com> References: <201809062330.w86NUphJ027262@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Sep-6, at 4:30 PM, Kirk McKusick <mckusick at mckusick.com> wrote: >> To: Kirk McKusick <mckusick@mckusick.com> >> Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems >> Date: Wed, 5 Sep 2018 16:38:35 -0700 >> Cc: bob prohaska <fbsd@www.zefox.net>, >> FreeBSD Filesystems <freebsd-fs@FreeBSD.org> >> >> On 2018-Sep-5, at 3:07 PM, Kirk McKusick <mckusick at mckusick.com> wrote: >> >>> The above three comparisons on the (relatively) I/O bound installworld >>> would be useful. Even if the TRIM consolidation does not help, it is >>> useful to know that it does not hurt. And running without TRIM would >>> also be a useful data point to measure the cost/savings of doing TRIM. >> >> I provided some initial figures for consolidation enabled vs. not in >> another message. It also noted other limitations of the testing via >> a Pine64+ 2GB. >> >> I've not done anything for "without trim". >> >>> It is a bit tricky to just turn off TRIM and then measure it, because >>> in the immediate aftermath of its having been used, it will leave >>> behind a legacy of easier to use flash areas yet not have the cost >>> of keeping them cleaned up. So, it might initially look like enabling >>> TRIM is a bad idea. Thus you would have to run many installworlds >>> without TRIM enabled to see what the long-term result of not using >>> TRIM turns out to be. >> >> It does not help that the ufs on /dev/mmcsd0 has over 60 GiBytes free >> and clang-cortexA53-installworld-poud is more like 3 GiBytes. There is >> also about 5.5 GiBytes outside any partition that I do not know >> the detailed status of for how I copied the e.MMC to the microssdxc >> card. >> >> I do have another microsdxc card of the same type that I could >> put into a USB device (so no TRIM) and dd a copy over to, disable >> TRIM on the new file system, and then boot from. But more might be >> required to avoid apparently "clean" blocks on the new microsdxc >> card. (For example, avoid having areas of all-zeros?) >> >> Any suggestions for what you would like to have set up for a >> TRIM disabled test? Do the Pine64+ 2GB limitation limit the >> value of the tests? >> >> >> The pine64+ 2GB is now doing a poudriere bulk that targets some >> x11 related ports --leading to 225 ports being attempted for >> the bulk run. It is going to be a while before it finishes. >> Almost certainly not today. (FYI: Consolidation is enabled.) >> This will use some part of that 60 GiBytes but likely not >> all that much of it. >> >> . . . A little while ago the x11 related builds completed and I installed 4 such ports explicitly (and 218 implicitly). No evidence of file system problems or other such. (X11 operation is untested.) > I concur that there is no experiment "without TRIM" that is likely to > produce any meaningful result. Okay. > Your tests with TRIM have been most helpful in helping to show that the > new TRIM code is not hazardous to the stability of the kernel. > Glad to help. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B9914A0D-69DC-4D3F-9BA4-D180462B2FA5>