You know what -- I went back and double-checked all the logs, and somehow
or other I must have recorded a timestamp wrong as 3:19:21 instead of
3:19:51.
The segfault did in fact happen at 3:19:51 a.m. which is exactly the same
time as my backup script moved on to the next filesystem.
So, it occurred during the unmount and lvremove of the snapshot volume.
It is, then, entirely expected that the device-mapper routines would
return an error if the device no longer existed when the task was run.
My apologies for mixing up the timestamps! And no bug in device-mapper,
just the one in e2fsprogs whch segfaulted in this circumstance instead of
dropping the device from its list. Having it fail outright, and not list
the device at all, is the correct behaviour for this situation -- just as
if the device had already been removed before the blkid routines were run.
- Philip
On Fri, 22 Feb 2008, Theodore Tso wrote:
On Fri, Feb 22, 2008 at 10:16:53AM -0600, Eric Sandeen wrote:
From a quick chat with agk, it sounds like outright failure is
appropriate. Sounds like most of the calls fail for reasons like ENOMEM
(but it might be nice if it returned that, eh?)
So the question then is why is it that Phillip was able to seeing
failures when he was creating and deleting snapshots?
I don't mind having blkid return a failure, but it may not fix
Phillip's scenario which he listed in BZ #433857; yeah, he won't have
a core dump, which is good, but it might mean that some or all of the
dm volumes disappear from the blkid results.
- Ted
--------------------------------------------+-------------------------------
Philip Spencer pspencer@xxxxxxxxxxxxxxxxxx | Director of Computing Services
Room 336 (416)-348-9710 ext3036 | The Fields Institute for
222 College St, Toronto ON M5T 3J1 Canada | Research in Mathematical Sciences
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
