From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Mhuln-0004By-E4 for garchives@archives.gentoo.org; Mon, 31 Aug 2009 00:29:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 686D1E0843; Mon, 31 Aug 2009 05:38:09 +0000 (UTC) Received: from IMPaqm4.telefonica.net (impaqm4.telefonica.net [213.4.129.19]) by pigeon.gentoo.org (Postfix) with ESMTP id 00B6DE0843 for ; Mon, 31 Aug 2009 05:38:08 +0000 (UTC) Received: from IMPmailhost6.adm.correo ([10.20.102.127]) by IMPaqm4.telefonica.net with bizsmtp id atbn1c00q2kvMAa3Qte8Ya; Mon, 31 Aug 2009 07:38:08 +0200 Received: from jesgue.homelinux.org ([78.136.66.163]) by IMPmailhost6.adm.correo with BIZ IMP id ate71c0033XLmEe1mte7qe; Mon, 31 Aug 2009 07:38:08 +0200 X-TE-authinfo: authemail="i92guboj.terra.es" |auth_email="i92guboj@terra.es" X-TE-AcuTerraCos: auth_cuTerraCos="cosuitera01" Received: from 192.168.0.10 (SquirrelMail authenticated user i92guboj) by jesgue.homelinux.org with HTTP; Mon, 31 Aug 2009 07:38:07 +0200 Message-ID: <5b7f62152b3704f3ce8c684a81cb8893.squirrel@jesgue.homelinux.org> In-Reply-To: <200908302326.53203.wonko@wonkology.org> References: <200908302138.14457.dirk.heinrichs@online.de> <98e072813338e844438b47ec9e95c0fd.squirrel@jesgue.homelinux.org> <200908302326.53203.wonko@wonkology.org> Date: Mon, 31 Aug 2009 07:38:07 +0200 Subject: Re: [gentoo-user] How to set udev rule? From: =?iso-8859-1?Q?Jes=FAs_Guerrero?= To: gentoo-user@lists.gentoo.org User-Agent: SquirrelMail/1.5.2 [SVN] Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: c15180d4-3106-40fd-a1d5-ff98cd09137e X-Archives-Hash: 37c5e8849ac2f029b8e376cd43e29c0b On Sun, August 30, 2009 23:26, Alex Schuster wrote: > Jes=FAs Guerrero writes: > > >> Then they wonder why the heck >> the file is not where it should be. I guess they never heard of cached >> writes. >> >> The correct thing to do is of course to umount it before, >> and then unplug it or whatever. > > I do so, it makes me feel better, but I wonder whether it is _really_ > necessary. It is. Nothing can guarantee that the data has been dumped to the disk unless you umount it first. You can reduce the chances of losing information by waiting before removing it. But if the system is loaded the writes can be deferred to a later time, when the system is idle. This can be partially mitigated by using the "sync" mount option, as you say below. :) Of course then the performance will drop, and the i/o scheduler will not have a chance to work as usual either because i/o ops will not be queued, which is the bad part of the deal. > I see Windows users do this all the time, without any problem > yet. Of course, the wait a little after writing to it, but a few second= s > after the blinking stops seem to be enough. Lucky guys. That, or when the file is not on the drive they come back and copy it again without you noticing it. This happens lots of times. I've seen it and I'll continue to see it as long as users don't understand what's going under the hood. That's what the safe removal feature in Windows is about, it's not there just to decorate your try, it exists for a reason. > And people are lazy, Yes, I am as well. But when integrity matters you really want to umount or at least sync before unplugging. I am a lazy guy, lazy like hell, but I always fasten my seat belt when I am going to drive. ;) > The > udev mouting rule is nice, but it leaves a lot of mounts when plugging = in > and out repeatedly. Mmmm, I am not sure I follow you. If you use a rule as described above you can remove the mount and even the mount point when the device is detached. Is not that what you mean? > When the system is mostly idle, I guess the writing to the stick would > not be delayed for a long time, so this should be quite safe. At least = if > the data is not that important. And if there are no writes, I see no > problem at all. If you don't have a problem with the chance to lose files that's ok. I just thought I'd point it out just in case, because the chance is there. A write operation can be deferred for a number of reasons. That's why "sync" (both as a command and as a mount option) was invented in first place. > There also is the sync option to mount, it should not be used on media > with limited number of write cycles, but I also guess that for my purpo= ses > this would not matter. Nowadays this shouldn't matter too much. The life cycle of ssd devices has been greatly expanded, and they also do some kind of balancing so all the blocks get the same usage. Even journal fs's shouldn't be much of a problem with any recent flash device. --=20 Jes=FAs Guerrero