From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 17:58:33 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 9A9351065689 for ; Sun, 4 Jul 2010 17:58:33 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 592978FC30 for ; Sun, 4 Jul 2010 17:58:33 +0000 (UTC) Received: by iwn35 with SMTP id 35so3088875iwn.13 for ; Sun, 04 Jul 2010 10:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=DD2FYYQsMYQJTGphXIkUSG0jPV4fo4BkvbDG8ctY7Z0=; b=KNxoLmWQyqkHmLnGJysfvWN1hy56onM75K+QVImWDX8UPFS3m1Urj0oXZOPxoQG9/2 tB/tkw3Ab4aIuV7S0itwY08QjLbzdrKStoqAmmPLS60myLK6YhRrmfBIYtNra+3clAOo dNeDta+zR/DRewzBao4Qamg5dZ57W9qQ4PbcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=APYRbSs3K62N8TzpdCKwHR1wGGw8N2YoGWWRSMMIuk00I9k8AbQIrDEq5wCVAOrEcx 52Qmqfojwz9cg87xkVoRV+1zpjddc8my+tf8gznlGjvtfGzORzY6KLyDI8YUlzvKWuH4 7kz+nM7PdsNQr0a/6gzfhki442jE2q63vMczA= Received: by 10.231.171.13 with SMTP id f13mr1800697ibz.103.1278266312531; Sun, 04 Jul 2010 10:58:32 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-128-180.dsl.klmzmi.sbcglobal.net [99.181.128.180]) by mx.google.com with ESMTPS id 34sm14291963ibi.0.2010.07.04.10.58.31 (version=SSLv3 cipher=RC4-MD5); Sun, 04 Jul 2010 10:58:31 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C30CBC6.1030507@dataix.net> Date: Sun, 04 Jul 2010 13:58:30 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 To: Kevin Oberman References: <20100704161528.762E21CC0D@ptavv.es.net> In-Reply-To: <20100704161528.762E21CC0D@ptavv.es.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Sun, 04 Jul 2010 17:58:33 -0000 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. Regards & Good luck, -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+