aboutsummaryrefslogtreecommitdiff
path: root/tests/fs-tests/stress/atoms/rndrm00.c
diff options
context:
space:
mode:
authorJehan Bing <jehan@orb.com>2009-06-08 13:43:26 -0700
committerArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2009-06-09 18:01:29 +0300
commitbc0cd0d9606c7d0c41d09a694b49bade159815b1 (patch)
tree2a4dc238b7c2b83794ba4d580fd1932a6a3b5e01 /tests/fs-tests/stress/atoms/rndrm00.c
parent59c537d0fd1af368eaeed5ec27e2336077c18691 (diff)
nandwrite: fix error handling
Artem Bityutskiy wrote: > Yes, write and erase failure mean that the erasblock is bad. But I think > marking a block as bad straight away is just dangerous. Who knows may be > this is a small glitch in a bus, or a software bug, or some-one > corrupted driver's memory, or whatever. This is why UBI is doing > eraseblock torturing before marking it as bad. And it is very careful > about error codes - only EIO code is considered as a reason to mark an > eraseblock as bad. Fixed broken behavior in case of write failure. More specifically: - Only try to mark a block bad if the errors are EIO. Other errors will abort the tool. - Also abort the tool if the marking fails instead of ignoring it. Signed-off-by: Jehan Bing <jehan@orb.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Diffstat (limited to 'tests/fs-tests/stress/atoms/rndrm00.c')
0 files changed, 0 insertions, 0 deletions