Illumos #4950 files sometimes can't be removed from a full filesystem #2784

Reviewed by: Adam Leventhal adam.leventhal@delphix.com
Reviewed by: George Wilson george.wilson@delphix.com
Reviewed by: Sebastien Roy sebastien.roy@delphix.com
Reviewed by: Boris Protopopov bprotopopov@hotmail.com
Approved by: Dan McDonald danmcd@omniti.com
Ported-by: Richard Yao richard.yao@clusterhq.com

Porting notes:
1. ZoL currently does not log discards to zvols, so the portion of this patch that
modifies the discard logging to mark it as freeing space has been discarded.

may_delete_now had been removed from zfs_remove() in ZoL. It has been reintroduced.
Illumos #5244 zio pipeline callers should explicitly invoke next stage #2828

References:
https://www.illumos.org/projects/illumos-gate//issues/5244
https://reviews.csiden.org/r/119/diff/#

Porting Notes:
1. The unported "2932 support crash dumps to raidz, etc. pools" caused a
merge conflict due to a copyright difference in module/zfs/vdev_raidz.c.
2. The unported "4128 disks in zpools never go away when pulled" and
additional Linux-specific changes caused merge conflicts in
module/zfs/vdev_disk.c.
3. Our changes to use the TQ_PUSHPAGE extension and vdev_file_taskq
caused merge conflicts in module/zfs/vdev_file.c. The taskq import that
I plan to send in the future would have prevented this particular
conflict.

Reviewed by: Matthew Ahrens mahrens@delphix.com
Reviewed by: Adam Leventhal ahl@delphix.com
Reviewed by: Alex Reece alex.reece@delphix.com
Reviewed by: Christopher Siden christopher.siden@delphix.com
Ported-by: Richard Yao richard.yao@clusterhq.com
Store common Linux xattrs as native SA with xattr=sa #2809

[dweeezil]

There are 2 commits here. The first, dweeezil/zfs@c53847e, fixes deletion of system attributes.

The second is a intended to be the foundation for fixing #2718 but it should otherwise be able to stand on its own.

I've given this patch stack fairly light manual testing as well as running the "pjd" posixacl test suite and some short ztest runs.

I'm submitting this now as a functional WIP to get feedback from other developers regarding the overall concept and its implementation. There are a handful of issues I'll point out about the code:

The list of xattrs to store as native SAs is stored statically in zpl_xattr.c which made it difficult to share with zdb. The same list (in a different format) exists within zdb.c as part of the new
dump_znode_native_sa_xattr() function.
The management of existing ZPL_DXATTR SAs required a helper function to translate from a zpl_attr_t to its name. As far as I could tell, there were no existing "upcalls" from the ZoL ZPL to the native
Solaris ZPL. Rather than trying to #include the ZPL definitions in zfs_sa.c, I simply added an appropriate extern declaration. This goes against the current coding style.
The ZPL_DXATTR SA cleanup performed by zfs_sa_remove_xattr adds overhead which could be avoided if it was known that no ZPL_DXATTRs exist. To that end, it's only invoked after determining whether a
ZPL_DXATTR exists (which should be a low-overhead operation).
I'd like to add a feature flag which is activated when a Native SA xattr is set for the first time; the feature flag would not be able to be deactivated. We might also want a feature flag to do the same
with the existing ZPL_DXATTR SAs.
I'd also like feedback on the first commit in this stack. I discovered the problem during testing. My concern is that all other OpenZFS implementations likely share the identical code. I think the
problem isn't seen often because SAs are rarely deleted. My test system created sort of a "perfect storm" by "stacking" all the variably-sized SAs at the ends of the registration.
Don't read space maps during import for readonly pools #2909

Normally when importing a pool the space maps for all top level
vdevs are read from disk. The space maps will be required latter
when an allocation is performed and free blocks need to be located.

However, if the pool is imported readonly then we are guaranteed
that no allocations can occur. In this case the space maps need
not be loaded.. A similar argument can be made for the DTLs
(dirty time logs).

Because a pool import will fail if the space maps cannot be read.
The ability to safely ignore them makes it more likely that a
damaged pool can be imported readonly to recover its contents.

Signed-off-by: Brian Behlendorf behlendorf1@llnl.gov
Issue #2831