There are some design issues and assumptions to clarify/sort through in relation to the blk virtualiser PR #86
[ ] Optimal block size:
As far as I know optimal block size depends on the filesystem that is stored on disk. Should it be the responsibility of the virtualiser to relay that information to clients? If so it would require the virtualiser or some other intermediary component to parse the metadata region for each partition in the block device in order to initialise the optimal block size. Current implementation ignores that field.
Resolved: Optimal block size refers to what the block device wants, not the filesystem. Changes will be made in a future PR
[ ] virtualiser policy:
When one client notifies the virtualiser, the virtualiser processes the queues from all clients in a loop. There is a implied higher priority for whoever the client is populating index 0, as it is always served first. Additionally, if the driver queue is full, client requests are dropped without replying failure to the clients, so clients would not know their request has been dropped.
[ ] The virtualiser should not be doing any copying and instead be using offsets into the DMA region. This was not done initially due to a limitation with our user-space UIO-based Linux drivers, however we should be optimising for the native driver case. Not the Linux user-space drivers. This more ideal model should be possible but we haven't been able to get it working yet.
There are some design issues and assumptions to clarify/sort through in relation to the blk virtualiser PR #86
[ ] Optimal block size:
As far as I know optimal block size depends on the filesystem that is stored on disk. Should it be the responsibility of the virtualiser to relay that information to clients? If so it would require the virtualiser or some other intermediary component to parse the metadata region for each partition in the block device in order to initialise the optimal block size. Current implementation ignores that field.Resolved: Optimal block size refers to what the block device wants, not the filesystem. Changes will be made in a future PR[ ] virtualiser policy: When one client notifies the virtualiser, the virtualiser processes the queues from all clients in a loop. There is a implied higher priority for whoever the client is populating index 0, as it is always served first. Additionally, if the driver queue is full, client requests are dropped without replying failure to the clients, so clients would not know their request has been dropped.
[ ] The virtualiser should not be doing any copying and instead be using offsets into the DMA region. This was not done initially due to a limitation with our user-space UIO-based Linux drivers, however we should be optimising for the native driver case. Not the Linux user-space drivers. This more ideal model should be possible but we haven't been able to get it working yet.