> On May 5, 2015, 10:44 p.m., Will Andrews wrote: > > It looks like this works by dirtying, in the user context (via > > dbuf_free_range), the L1 dbufs for the affected range, which means that all > > such dbufs and all its parents will be kept in ARC through the end of the > > sync? Could that possibly delay transaction groups (via serialized dbuf > > reads), or am I understanding right that is that mitigated by the fact that > > dmu_tx_hold_free prefetches them? So all affected dbufs should already be > > DB_CACHED? Presuming your ARC is large enough? > > Matthew Ahrens wrote: > "It looks like this works by dirtying ..." - Yes. > > "mitigated by the fact that dmu_tx_hold_free prefetches ..." - Yes on all > counts. It is probably still cached from the dmu_tx_hold_free. If it is > not, then we are doing the read with the tx assigned, preventing this txg > from quiescing (this is the same as any operation e.g. zfs_write()). This is > still far preferable to doing the reads in syncing context. > > Will Andrews wrote: > I'm not sure there is much difference between holding up a txg in syncing > context vs. in open context. zfs_write et al generally have a small upper > bound on the amount of changes they need committed in a tx. > > Wouldn't it be better to do something like one of these: > - Dirty the dbufs at the same time that they are prefetched, so they > can't be evicted even if the system is churning its ARC > - Chunk free range deletion in a manner similar to async zfs destroy > (i.e. via a special bplist object, if not the same one)
"I'm not sure there is much difference" -- The difference is that (as with zfs_write), the amount of work in each transaction (in open context) is bounded. dmu_free_long_range() chunks the work into transactions, limiting the number of indirect blocks that are touched by each transaction. In the current code, we can assign an unlimited number of these transactions to a single txg, thus causing it to do a huge amount of work. "Wouldn't it be better" -- potentially yes. Are you offering to write that code? :-) - Matthew ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/218/#review683 ----------------------------------------------------------- On May 5, 2015, 9:10 p.m., Matthew Ahrens wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.csiden.org/r/218/ > ----------------------------------------------------------- > > (Updated May 5, 2015, 9:10 p.m.) > > > Review request for OpenZFS Developer Mailing List. > > > Bugs: 5911 > https://www.illumos.org/projects/illumos-gate//issues/5911 > > > Repository: illumos-gate > > > Description > ------- > > 5911 ZFS "hangs" while deleting file > > Original author: Matthew Ahrens > > > Diffs > ----- > > usr/src/uts/common/fs/zfs/sys/dbuf.h > c542c8aec875a20374d80d2f61bed856515c9c88 > usr/src/uts/common/fs/zfs/dnode_sync.c > bb18718bed73974556f03abec01e3bf31cb06a9d > usr/src/uts/common/fs/zfs/dnode.c 12d8db76faed60cc9ddf80877b5f91090214da44 > usr/src/uts/common/fs/zfs/dmu_tx.c 56ce2f0c279f8ac445ae4627713ea121dc378e0b > usr/src/uts/common/fs/zfs/dbuf.c 465dfd08b2302493b38e561432bf320c05d1f9f6 > > Diff: https://reviews.csiden.org/r/218/diff/ > > > Testing > ------- > > ztest > zfs test suite > working on manual testing > > http://jenkins.delphix.com/job/zfs-precommit/2227/ > > > Thanks, > > Matthew Ahrens > >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
