From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 23:53:02 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5705C106566B for ; Mon, 5 Jul 2010 23:53:02 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 05F158FC08 for ; Mon, 5 Jul 2010 23:53:01 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o65Nqecv020655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Jul 2010 16:52:40 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 0CC531CC0D; Mon, 5 Jul 2010 16:52:40 -0700 (PDT) To: jhell In-reply-to: Your message of "Sun, 04 Jul 2010 13:58:30 EDT." <4C30CBC6.1030507@dataix.net> Date: Mon, 05 Jul 2010 16:52:40 -0700 From: "Kevin Oberman" Message-Id: <20100705235240.0CC531CC0D@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-05_06:2010-02-06, 2010-07-05, 2010-07-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1007050131 Cc: stable@freebsd.org Subject: Re: Odd behavior of labels on different filesystem types X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 23:53:02 -0000 > Sender: "J. Hellenthal" > Date: Sun, 04 Jul 2010 13:58:30 -0400 > From: jhell > > On 07/04/2010 12:15, Kevin Oberman wrote: > >> Sender: "J. Hellenthal" > >> Date: Sun, 04 Jul 2010 01:55:20 -0400 > >> From: jhell > >> > >> On 07/03/2010 16:51, Kevin Oberman wrote: > >>> I have run into an odd behavior in 8-stable that I can't see a reason > >>> for. > >>> > >>> If I have a FAT32 formatted removable drive, I get /dev entries for it > >>> as both /dev/msdosfs/LABEL and /dev/ufsid/ID. When I mount the > >>> filesystem, the /dev/ufsid label is removed, but the other two remain. > >>> > >>> If I have a UFS filesystem on the disk, I have similar devices except > >>> that the LABEL is /dev/ufs/LABEL. But, when the UFS device is mounted, > >>> the /dev/ufsid/ID AND the /dev/ufs/LABEL devs are both deleted. > >>> > >>> I'm not sure which is "right", but I can't see the reason for the > >>> different behavior and it has caused a fair bit of trouble when working > >>> with gnome-mount as I can't unmount a ufs device. When the > >>> /dev/ufs/LABEL device is created again on the umount, gnome-mount sees a > >>> new device and immediately re-mounts it. > >>> > >>> Can this inconsistency be corrected? > >> > >> Can you try to zero out that disk first i.e. > >> dd if=/dev/zero of=/dev/DISK bs=4m > >> > >> Then format your msdos fat part and relabel it. You should not see a > >> dev/ufsid/ label for this anymore. I believe that for some reason the > >> ufsid metadata or whatever you want to call it some how has been left > >> behind and is still being read for whatever reason and can be confirmed > >> by this. > >> > >> As for /dev/ufs/LABEL /dev/ufsid/ID /dev/device when you mount one the > >> others should disapear so this is correct behavior. > > > > Thanks for the suggestion. I will try a device which has never had a UFS > > file system and see if the ufsid device is created. Looks like the > > former is an issue with geom tasting and it would be nice to get it > > fixed, but it is not what is causing my problem. It is the latter issue > > that causes the problems with gnome-mount. > > > > The real issue for me is that /dev/ufs/LABEL is removed on a mount while > > /dev/msdosfs/LABEL remains. hald easily works around ufsid by ignoring > > it, but the /dev/FS/LABEL has to be acted upon differently depending on > > which filesystem is involved. > > Do you use those labels for anything ? if not, I worked around this > while I used gnome for a period with devfs.rules(5) example follows. > > rc.conf(5) add devfs_system_ruleset="your_system" > > [your_system=10] > add path 'ufsid' hide > add path 'msdosfs' hide > add path 'ufs' hide > add path 'iso9660' hide > add path 'reiserfs' hide > add path 'ntfs' hide > add path 'ext2fs' hide > add path 'gpt' hide > > And you can do the same for the actual devices that you use a label for, > so mounting devices like daN can just be done from /dev/label/LABEL. > > add path 'da0' hide # Do this only after it is labeled. > add path 'label/DA0LABEL' mode 0600 user jhell group jhell > > With a little toying of the above you should get the desired effect you > want in gnome. I do find it frustrating having to resort to using only > generic labels for situations like this and believe firmly that the > generic label should take precedence over all labels except gpt & ufsid > and result in the other name-brand labels disappearing not causing this > frustration to happen. Having the multiple layers of labels available > IMO is cause for confusion. > > Final note before I stretch this out like the Armstrong figurine ;), > there was a case where I was using the module instead of having > GEOM_LABEL option built into the kernel, this being loaded after the > machine was already booted caused some strange results with the labels > that I know of on 7.2-STABLE. I don't know if this still exists but the > result from that was multiple labels still being available under /dev > while its counterpart label was mounted. That caused Gnome/hald to get > pretty confused. Thanks. It worked...and it didn't help. Something else in Gnome2.30 is triggering this, I guess. The disk now mounts as /dev/da0s1d, just like it should, but it is still re-mounting as soon as I unmount it. This is a problem for ufs disks, but not for FAT. Since most people are probably using this for mounting thumb drives which are almost always FAT, I guess it has not been seen too much. Guess it's time to take this to the gnome list. Thanks again. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751