Conversation
initialize disk selection policy when starting RAID.
implementation
setting the RAID1 module's thread to use realtime scheduler
arthurp
left a comment
There was a problem hiding this comment.
Mostly nits that should be trivial to fix.
The complex bit is creating and configuring the block devices. See comments below.
| pub fn handle_requests(&self) { | ||
| let request = self.queue.dequeue(); | ||
| info!("Handle Request: {:?}", request); | ||
| // info!("Handle Request: {:?}", request); |
There was a problem hiding this comment.
Let's not leave commented code. Either keep it or remove it. I'm find with either.
| // let status = BioStatus::Complete; | ||
| // parent.complete(status); |
There was a problem hiding this comment.
Remove commented code. Or justify it
| self.bio_submission_oqueue().produce(bio)?; | ||
| let device_index = self.device.device_index.load(Ordering::Relaxed); | ||
| bio.prepare_enqueue(reply_handle, self.queue.clone(), device_index); | ||
| let producer = self.bio_submission_oqueue().attach_value_producer()?; |
There was a problem hiding this comment.
Producers are Sync. So you can store it in self if you like. I'm not totally sure of the best way to handle this pattern of producing from various threads though. That decision is for a different PR, so whatever works if fine.
| #[cfg(not(baseline_asterinas))] | ||
| RPCError(RPCError), | ||
| /// The OQueue attachment errors | ||
| /// The OQueue errors | ||
| #[cfg(not(baseline_asterinas))] | ||
| OQueueAttachError(OQueueAttachError), | ||
| OQueueError(OQueueError), |
There was a problem hiding this comment.
If you use snafu and ostd_error (which you should). Then the From implementations can be automatically generated by marking the variant #[snafu(transparent)]. Search for that for examples.
| CC := gcc | ||
| C_FLAGS := -Wall -Werror | ||
| # C_FLAGS := -Wall -Werror | ||
|
|
There was a problem hiding this comment.
I do want to continue banning warnings. If there are specific warnings causing problems. I'm happy to help.
| @dd if=/dev/zero of=$(EXT2_IMAGE) bs=2G count=1 | ||
| @dd if=/dev/zero of=$(EXT2_IMAGE) bs=1G count=2 |
| -drive if=none,format=raw,id=r0,file=./test/build/raid1_0.img,cache=directsync \ | ||
| -drive if=none,format=raw,id=r1,file=./test/build/raid1_1.img,cache=directsync \ | ||
| -drive if=none,format=raw,id=d0,file=./test/build/capture.img \ | ||
| -drive if=none,format=raw,id=d1,file=./test/build/capture_legacy.img \ | ||
| -drive if=none,format=raw,id=r0,file=/dev/nvme0n1p1,cache=directsync \ | ||
| -drive if=none,format=raw,id=r1,file=/dev/nvme1n1p1,cache=directsync \ | ||
| -drive if=none,format=raw,id=r2,file=/dev/nvme2n1p1,cache=directsync \ | ||
| " |
There was a problem hiding this comment.
This can't be like this because it will only work on a specifically configured machine. Maybe introduce an environment variable which takes three file names "r0,r1,r2" and uses them for the raid devices. Given file size concerns maybe we don't want to auto-create raid devices in general either. So maybe have an "auto" value for the variable which trigger automatic file setup like before.
I'm very open to other ideas.
| -drive if=none,format=raw,id=r0,file=./test/build/raid1_0.img \ | ||
| -drive if=none,format=raw,id=r1,file=./test/build/raid1_1.img \ | ||
| -drive if=none,format=raw,id=r0,file=/dev/nvme0n1p1 \ | ||
| -drive if=none,format=raw,id=r1,file=/dev/nvme1n1p1 \ | ||
| -drive if=none,format=raw,id=r2,file=/dev/nvme2n1p1 \ |
There was a problem hiding this comment.
I'm not sure how to handle this given the discussion of multiple configurations above. Do you know off hand when this file is actually used? I think, most of the time, it's actually ignored. If we can understand when this file is actually used we can potentially remove the raid devices entirely and just document that raid isn't configured in the specific configuration.
As one of the intermediate PR of #170, merging the following commits:
VirtIOmodule to the new OQueue.