Am 12.04.2015 um 23:33 schrieb Andrea Scian: >>> I think is always useful to give some additional information in userspace, >>> from both debugging and diagnostic point of view. >> The question is, why does userspace care? > > Because the userspace trigger it
As written in the previous mail, then userspace knows anyway the state. > >> Other UBI operations are also not visible... > > I don't really know much about UBI internals, but I think not many operation > are triggered from userspace (apart from ubiformat and mount ;-) ) > > >>>> But I can add this feature, no problem. >>> Thanks ;-) >>> >>> May I ask if can be useful to abort the (IMHO quite long running) operation? >>> I think it can be useful to save power, e.g. when running on batteries: >>> smart systems will trigger the operation when charging and aborting it if >>> on batteries (or on low >>> batteries). >> If the system is running on low power mode just don't trigger the run... >> Userspace controls it. > > It heavily depends on how long the operation takes, we may have 4 to 32 GiB > devices so I think it may take more than just a few minutes to scan the whole > device (and additional > time depending on how many scrub operation are needed). > You may start the operation when power is not an issue (e.g. while charging) > and when it is (e.g. when running on batteries and you need to save any mAh > you have ;-) ) it may be > still running for a while.. > I know that this is some kind of advance feature, but I would like to point > this out for comments. In such a scenario one definitely wants the emerging ioctl() interface. >> >>> What happens if the system need to reboot in the middle of scanning? >> Just reboot, UBI can handle that. Work will be canceled. > > Thanks for the confirm > >> >>> Probably nothing at all but I think it's worth asking ;-) >>> Anyway I think it's better if we can, on runlevel 6, shutdown the operation >>> in a clean way >>> >>> To ask a little bit more from the current implementation, can it be useful >>> expand sysfs entry with the current status (stopped, running, completed)? >>> In this way the userspace knows whenever the operation it has triggered, it >>> completed successfully or something interrupt it (e.g. an internal error). >>> I will schedule a new >>> operation sooner if I have no evidence that the last one completed >>> successfully.. WDYT? >>> But maybe all of this stuff will be implemented inside a daemon with >>> additional ioctl() (IIRC Richard already is working on this). >> That's the plan. The interface proposed in that patch series it designed to >> be a simple replacement for the dd if=/dev/ubiXY of=/dev/null hack. > > dd can be stopped if needed and you may also have the progress status :-) > > for sure you probably don't need all of the above additional stuff but it may > be useful anyway > Maybe it's better to have an initial working implementation and add some more > (backward compatible?) features later. I agree. BTW: Thanks a lot for your comments, Boris and Andrea! Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
