| To: | <strr-debian@xxxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | RE: Two XFS involving stack traces from Debian's 2.6.26-2-amd64 |
| From: | "Michael Monnerie" <michael.monnerie@xxxxxxxxxxxxxxxxxxx> |
| Date: | Thu, 1 Oct 2009 23:17:56 +0200 |
| Cc: | <xfs@xxxxxxxxxxx> |
| In-reply-to: | <4AC4B954.9050303@xxxxxxxxxxxxxxxxxx> |
| References: | <4AC45B72.9060500@xxxxxxxxxxxxxxxxxx> <200910011244.37489@xxxxxx> <4AC4B954.9050303@xxxxxxxxxxxxxxxxxx> |
| Thread-index: | AcpCpLAZVvMAnUicSU2IU1ChxJraGgAN4Dyg |
> Thanks, I've changed it as you suggested. It's true a second call > to umount > does unmount it (well it disappears from /proc/mounts anyway). I've had the same problem with a backup script to a NAS. It takes a long time until the buffers flush or so, a loop with up to 5 umount retries has to be done. But that works always, at least ;-) > However lvremove still does not succeed because it still believes > the volume to be open. Even after umount? Hm, that smells like a bug. Maybe make umount && sleep 5 && lvremove if that works a timing problem it is, says Yoda. mfg zmi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [PATCH] xfststests 220: test for prealloc/delalloc/reserved space recapture, Eric Sandeen |
|---|---|
| Next by Date: | XFS/driver bug or bad drive?, David Engel |
| Previous by Thread: | Re: Two XFS involving stack traces from Debian's 2.6.26-2-amd64, Stuart Rowan |
| Next by Thread: | [PATCH] xfststests 220: test for prealloc/delalloc/reserved space recapture, Eric Sandeen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |