From: Richard Weinberger <richard@nod.at> To: Andrea Scian <rnd4@dave-tech.it> Cc: linux-mtd@lists.infradead.org, Boris Brezillon <boris.brezillon@free-electrons.com>, linux-kernel@vger.kernel.org, dedekind1@gmail.com Subject: Re: [PATCH 4/4] UBI: Implement bitrot checking (linux-mtd Digest, Vol 145, Issue 24) Date: Sun, 12 Apr 2015 23:42:27 +0200 [thread overview] Message-ID: <552AE6C3.8040605@nod.at> (raw) In-Reply-To: <552AE48C.8070500@dave-tech.it> 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
WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at> To: Andrea Scian <rnd4@dave-tech.it> Cc: Boris Brezillon <boris.brezillon@free-electrons.com>, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, dedekind1@gmail.com Subject: Re: [PATCH 4/4] UBI: Implement bitrot checking (linux-mtd Digest, Vol 145, Issue 24) Date: Sun, 12 Apr 2015 23:42:27 +0200 [thread overview] Message-ID: <552AE6C3.8040605@nod.at> (raw) In-Reply-To: <552AE48C.8070500@dave-tech.it> 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
next prev parent reply other threads:[~2015-04-12 21:42 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-03-29 12:13 UBI: Bitrot checking Richard Weinberger 2015-03-29 12:13 ` Richard Weinberger 2015-03-29 12:13 ` [PATCH 1/4] UBI: Introduce ubi_schedule_fm_work() Richard Weinberger 2015-03-29 12:13 ` Richard Weinberger 2015-03-29 12:13 ` [PATCH 2/4] UBI: Introduce prepare_erase_work() Richard Weinberger 2015-03-29 12:13 ` Richard Weinberger 2015-03-29 12:13 ` [PATCH 3/4] UBI: Introduce in_pq() Richard Weinberger 2015-03-29 12:13 ` Richard Weinberger 2015-03-29 12:13 ` [PATCH 4/4] UBI: Implement bitrot checking Richard Weinberger 2015-03-29 12:13 ` Richard Weinberger 2015-04-02 17:34 ` Andrea Scian 2015-04-02 17:34 ` Andrea Scian 2015-04-02 17:54 ` Richard Weinberger 2015-04-02 17:54 ` Richard Weinberger 2015-04-02 19:19 ` Andrea Scian 2015-04-02 19:19 ` Andrea Scian 2015-04-08 10:34 ` Richard Weinberger 2015-04-08 10:34 ` Richard Weinberger 2015-04-08 21:02 ` Andrea Scian 2015-04-08 21:02 ` Andrea Scian 2015-04-08 11:48 ` David Oberhollenzer 2015-04-12 14:12 ` Boris Brezillon 2015-04-12 16:09 ` Richard Weinberger 2015-04-12 16:43 ` Boris Brezillon 2015-04-12 16:55 ` Richard Weinberger 2015-04-12 20:42 ` [PATCH 4/4] UBI: Implement bitrot checking (linux-mtd Digest, Vol 145, Issue 24) Andrea Scian 2015-04-12 20:42 ` Andrea Scian 2015-04-12 21:01 ` Richard Weinberger 2015-04-12 21:01 ` Richard Weinberger 2015-04-12 21:30 ` Boris Brezillon 2015-04-12 21:37 ` Richard Weinberger 2015-04-12 21:33 ` Andrea Scian 2015-04-12 21:33 ` Andrea Scian 2015-04-12 21:42 ` Richard Weinberger [this message] 2015-04-12 21:42 ` Richard Weinberger 2015-04-13 17:17 ` linux-mtd digest emails (was Re: [PATCH 4/4] UBI: Implement bitrot checking) Brian Norris 2015-04-13 17:17 ` Brian Norris 2015-04-12 15:14 ` [PATCH 4/4] UBI: Implement bitrot checking Boris Brezillon 2015-04-12 16:14 ` Richard Weinberger 2015-04-12 16:31 ` Boris Brezillon 2015-04-12 16:32 ` Richard Weinberger 2015-04-12 17:01 ` Boris Brezillon 2015-04-12 17:09 ` Richard Weinberger 2015-04-12 19:20 ` Boris Brezillon 2015-04-12 19:53 ` Richard Weinberger 2015-04-12 21:24 ` Boris Brezillon 2015-04-12 21:34 ` Richard Weinberger 2015-04-13 3:36 ` nick 2015-04-12 17:36 ` Richard Weinberger [not found] <mailman.40253.1428858576.22890.linux-mtd@lists.infradead.org> [not found] <mailman.38750.1427638218.22890.linux-mtd@lists.infradead.org>
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=552AE6C3.8040605@nod.at \ --to=richard@nod.at \ --cc=boris.brezillon@free-electrons.com \ --cc=dedekind1@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=rnd4@dave-tech.it \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.