[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 00/10] preallocate filter
From: |
Vladimir Sementsov-Ogievskiy |
Subject: |
Re: [PATCH v5 00/10] preallocate filter |
Date: |
Fri, 28 Aug 2020 00:08:20 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 |
21.08.2020 17:11, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
Here is a filter, which does preallocation on write.
In Virtuozzo we have to deal with some custom distributed storage
solution, where allocation is relatively expensive operation. We have to
workaround it in Qemu, so here is a new filter.
I have a problem now with this thing.
We need preallocation. But we don't want to explicitly specify it in all the
management tools. So it should be inserted by default. It's OK for us to keep
this default different from upstream... But there are problems with the
implicitly inserted filter (actually iotests fail and I failed to fix them)
1. I have to set bs->inherits_from for filter and it's child by hand after
bdrv_replace_node(), otherwise bdrv_check_perm doesn't work.
2. I have to set filter_bs->implicit and teach bdrv_refresh_filename() to ignore
implicit filters when it checks for drv->bdrv_file_open, to avoid appearing of
json in backing file names
3. And the real design problem, which seems impossible to fix: reopen is
broken, just because user is not prepared to the fact that file child is a
filter, not a file node and has another options, and don't support options of
file-posix.
And seems all it (and mostly [3]) shows that implicitly inserting the filter is
near to be impossible..
So, what are possible solutions?
In virtuozzo7 we have preallocation feature done inside qcow2 driver. This is
very uncomfortable: we should to handle each possible over-EOF write to
underlying node (to keep data_end in sync to be able to shrink preallocation on
close()).. I don't like this way and don't want to port it..
Another option is implementing preallocation inside file-posix driver. Then,
instead of BDRV_REQ_NO_WAIT flag I'll need to extend serialising requests API
(bdrv_make_request_serialising() is already used in file-posix.c) to dupport
no-wait behavior + expanding the serialising request bounds. This option seems
feasible, so I'll try this way if no other ideas.
Filter is obviously the true way: we use generic block layer for native request
serialising, don't need to catch every write in qcow2 driver, don't need to
modify any other driver and get a universal thing. But how to insert it
implicitly (or at least automatically in some cases) and avoid all the problems?
--
Best regards,
Vladimir
[PATCH v5 08/10] iotests.py: add verify_o_direct helper, Vladimir Sementsov-Ogievskiy, 2020/08/21
[PATCH v5 09/10] iotests.py: add filter_img_check, Vladimir Sementsov-Ogievskiy, 2020/08/21
[PATCH v5 10/10] iotests: add 298 to test new preallocate filter driver, Vladimir Sementsov-Ogievskiy, 2020/08/21
Re: [PATCH v5 00/10] preallocate filter,
Vladimir Sementsov-Ogievskiy <=