[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the umount() saga for regular linux desktop users
- From: Ush <ofeeley@xxxxxxxxx>
- Date: Fri, 31 Dec 2004 09:48:41 -0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=bbKDe6KwHgSEK/6tRzJ37p9CL2EHeHDDEL3B9YRzMBVvglA1AD7LP6t9YoscJnFhGFZSM8AUqETOZsLgSS4QxCpID4wWieFYZw1tf+GCvn7k0kYUXoLBikowuGlnlEZ50aBaq83iB6Cyt3K7wmEjvFp+ABJ+4jgb+1cPYnW39t0=
- References: <200412311741.02864.wh@designed4u.net>
On Fri, 31 Dec 2004 17:41:02 +0000, William <wh@xxxxxxxxxxxxxx> wrote:
> Regularly, when attempting to umount() a filesystem I receive 'device is busy'
> errors. The only way (that I have found) to solve these problems is to go on
> a journey into processland and kill all the guilty ones that have tied
> themselves to the filesystem concerned.
Even a lazy umount doesn't work? "umount -l <filesystem-name>"
> In my opinion, in order for linux to be trully user friendly, "a umount()
> should NEVER fail" (even if the device containing the filesystem is no
> longuer attached to the system). The kernel should do it's best to satisfy
> the umount request and cleanup. Maybe the kernel could try some of the
> following:
Would it be user-friendly if this forcible umount caused the user to lose data?
Oisin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Follow-Ups:
References: