On Fri, February 4, 2011 09:30, Pawel Jakub Dawidek wrote: > But in most cases we don't need TRIM to be so perfect. My > current idea is to delay TRIM operation for some number of transaction > groups. For example if block is freed in txg=5, I'll send TRIM for it > after txg=15 (if it wasn't reassigned in the meantime). This is ok if > we crash before we get to txg=15, because the only side-effect is that > next write to this range might be a little slower.
Off the top of my head, I can then of two instances where non-recent blocks would be needed: * snapshots * importing via recovery mode ("zpool import -F mypool") For the latter, given that each vdev label can have up to 128 uberblocks, recovery mode import can go back at least 128 transactions for a single non-mirrored device, so you'd potentially need to not TRIM at least 128 transactions back for the worst case. Of course if you have a pair of mirrored vdevs/disks, and each one has 128 uberblocks, that's potentially 256 txgs that you can recover from (and it goes up the more vdevs you have of course). That may be excessive, but perhaps there could be a tunable sysctl on a max amount to go back TRIMing (defaulting to 128? 64? 32?). I'm not sure how ZFS keeps track of snapshots: is there something in-memory, or is it necessary to walk the tree? Perhaps getting a list of snapshots, getting the oldest birth time (i.e., smallest txg), and TRIMing and blocks that have one less than that number? Given that txgs are committed every 5-30s, and I/O isn't done between them, that "idle" time could be utilized for sending TRIM commands? Presumably the Oracle folks are looking at this as well internally. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss