Date: Tue, 4 Sep 2018 00:06:21 -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: <3F4C9F6F-667A-4E71-A73F-31CF6A0E754A@yahoo.com> In-Reply-To: <392FF90D-6D90-457B-94D2-9C4A05B46309@yahoo.com> References: <201808240504.w7O54SPJ067702@chez.mckusick.com> <392FF90D-6D90-457B-94D2-9C4A05B46309@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Test status update. I give some details of the test context and complications/limitations as well.] On 2018-Aug-23, at 10:58 PM, Mark Millard <marklmi at yahoo.com> wrote: > On 2018-Aug-23, at 10:04 PM, Kirk McKusick <mckusick at mckusick.com> = wrote: >=20 >> So are you in a position to try out the TRIM consolidation = implementation? >> In particular to see if it helps? >=20 > The Pine64+ 2GB that I have access to is in the middle of > a poudriere-devel bulk that probably has 24 hours or more > to go. That will delay anything that I might try. >=20 > I normally do not have the root file system and swap partition > run on a microsd card. So I do not have a history to compare > against. (I'd seen reports on the lists and just avoided the > issues up front.) I'm not sure of a good way to test at this > point. I might just end up gstat -pd monitoring a self-hosted > buildworld buildkernel or some such. Suggestions welcome. >=20 > Swap partitions do not get TRIMs and swap files are greatly > unreliable. (For the later see: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 > for what I'm referring to.) So the testing would likely be > just for the file system activity, with any swapping mixed > in the activity. >=20 > Once the poudriere-devel finishes it will take a bit to > set up a microsd card environment that is modern enough > to have the changes. So may be next week sometime? >=20 > Hopefully the: >=20 > # umount /mnt > pine64# tunefs -tenable /dev/mmcsd0s2a > tunefs: issue TRIM to the disk set >=20 > information will enable Bob P. to be able to do some > rpi3 and/or rpi2 testing. But I do not know if he has > a context were he can have some microsd card(s) that > he uses in an unmounted but accessible status. (I > have such a context.) >=20 >=20 > If FreeBSD could still boot such, I'd have tested > an e.MCC on an adapter card plugged into the microsd > slot. But when I took my large jump to head -r337400 > I discovered that combination no longer booted. So, > unless the status has changed after -r377400 when I > update, I can not test the e.MMC via sdcard-slot > context on the Pine64+ 2GB. I finally have access to a mmcsdxc card of about the same capacity as the on-an-adpater e.MMC that I used to use with the Pine64+ 2GB. I've copied things over, enabled trim on the (root) file system, and have "vfs.ffs.dotrimcons: 1". I did a fsck_ffs -E. The complete UFS (root) file system and the swap partition are on the microsdxc card, no other storage devices involved. (Swap not getting trim but the UFS file system getting it.) I'm doing an incremental -j4 buildworld buildkernel in this environment, jumping from a build of -r337400 to -r338450, but the Pine64+ 2GB is running -r338341. The build removes old files as it goes along. We will see how it goes. It is using "vm.pageout_oom_seq: 120". I'm using: LDFLAGS.lld +=3D -Wl,--no-threads I'll note that Ian Lepore reported in an exchange about RPI3 testing: QUOTE Trim consolidation at the ufs layer might not have as much effect on mmcsd as it does on other devices. The mmcsd driver has always consolidated adjacent trim requests itself even when they arrive in the IO queue as a large number of small BIO_DELETE commands. It assembles blocks of adjacent deletes until they reach the size of a full erase block, then issue one erase command (I've never been convinced that doing so is necessary, to me the sd spec implies you can delete individual sectors). END QUOTE I've no known, good means of isolating and comparing/contrasting the two consolidations (vs. the combination of both). As stands, at best I'll be able to report if I see any failures or evidence of any bottlenecks. (Similarly for a later poudriere-devel bulk.) The microsdcx card tested for this is from a: Sandisk Ultra 128GB Micro SDXC UHS-I Card with Adapter = SDSQUAR-128G-GN6MA It has the application "A1" rating. About 2/3 of the UFS partition is "Avail". About 5.5 GiByte of the microsdcx card is not in any partition (but that was dd'd from the e.MCC too and I do not know how to readily trim those areas). Other points of context: The Pine64+ 2GB is running a non-debug kernel (but with symbols), as is my norm unless I'm looking into a failure. =3D=3D=3D 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?3F4C9F6F-667A-4E71-A73F-31CF6A0E754A>