Matthew Ahrens wrote:
> I think you're saying you have a zvol with HFS+ on top, and that when you
> mount the HFS+ volume, it sends a lot of unmap requests to the zvol, which
> is slow.
> 
> Before we get into complicated solutions, I have some stupid questions:
> 
>  - Why does it need to issue a zillion unmaps every time you mount?

Ask Apple!

But yes, I suppose if you have a device that supports DISCARDs, and you
(the user) wants to receive unmaps, XNU kernel goes through all empty areas
on mount and issues unmap for each. Even for areas that have already been
discarded, it seems.

I don't think we can detect those unmap requests for already unmapped
areas? Easily?


> 
>  - Could you just ignore the UNMAPs? (obvious answer is yes, but does it
> hurt anything else)

Of course you can. Don't buy SSDs is one way! Disabling unmap support in OS
also works. But I guess they added unmap to devices, and operating systems,
for a reason, and should the user want them enabled, 20 mins to mount is
undesirable.. So we were checking to see if we could do something trivial
to lessen the effect.  People running the experimental code report
happiness, but that doesn't mean it's correct :)


> 
>  - Do you have this unmap performance fix?
>     4873 zvol unmap calls can take a very long time for larger datasets

Yes. Makes little difference. It is more the high number of commits that
take a while to go through.

I suspect only OSX and FreeBSD have this concern, as the other platforms do
not yet fully support devices with DISCARD. But I don't know for sure.


-- 
Jorgen Lundman       | <[email protected]>
Unix Administrator   | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo    | +81 (0)90-5578-8500          (cell)
Japan                | +81 (0)3 -3375-1767          (home)
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer

Reply via email to