malahal@xxxxxxxxxx wrote: > Look at this patch > http://permalink.gmane.org/gmane.linux.kernel.device-mapper.devel/4973 > > It essentially generates an uevet and waits for the user level code to > act on it and send a message to unblock it. This patch was posted more then a year ago, and I could not find any discussion on this issue/patch in the mailing list archive. What was the conclusion of the discussion about this patch? Are there any discussions outside this mailing list? I think data corruption is really a serious problem even if it has very small chance to happen. If it is a known problem, we need to fix it. Don't you agree? I roughly looked your patch, and I understand it is one of the approach to fix this issue. I have just one concern about delay. When 'unblock' message is delayed for some reason (by dmeventd?), all write I/Os from applications need to be waited, and many I/Os might come in a write queue and be blocked during 'block' status. Thanks, Taka -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
