For any provider, GEOM_LABEL strictly checks that ufs occupied all its space. But filesystem can be smaller, in case if newfs(8) was run with -r flag. So, GEOM_LABEL is not compatible with newfs -r flag. When check is more permissive (as in attached patch) all work OK: [pts/0] root@dash:/usr/home/dark# uname -rp 8.1-STABLE i386 [pts/0] root@dash:/usr/home/dark# ll /dev/ufsid/ total 0 crw-r----- 1 root operator 0, 93 22 ÓÅÎ 17:24 4992d90831a79611 [pts/0] root@dash:/usr/home/dark# mdconfig -s 32m md0 [pts/0] root@dash:/usr/home/dark# newfs -r 4 -U /dev/md0 /dev/md0: 32.0MB (65532 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 8.00MB, 512 blks, 1024 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 16544, 32928, 49312 [pts/0] root@dash:/usr/home/dark# ll /dev/ufsid/ total 0 crw-r----- 1 root operator 0, 93 22 ÓÅÎ 17:24 4992d90831a79611 crw-r----- 1 root operator 0, 118 22 ÓÅÎ 13:38 4c99ce860db39b88 [pts/0] root@dash:/usr/home/dark# glabel status Name Status Components ntfs/sys N/A ada0s1 msdosfs/SYS N/A ada0s2 msdosfs/BIOS N/A ada0s3 ntfs/BIG N/A ada1s2 ufsid/4992d90831a79611 N/A ada1s1a ufsid/4c99ce860db39b88 N/A md0 Fix: Use attached patch. Patch attached with submission follows: How-To-Repeat: radius# uname -rp 8.1-20100726-SNAP i386 radius# ll /dev/ufsid/ total 0 crw-r----- 1 root operator 0, 98 21 ÓÅÎ 22:01 4c98f1c148b0469b crw-r----- 1 root operator 0, 99 21 ÓÅÎ 22:01 4c98f1c978a6bb52 radius# mdconfig -s 32m md0 radius# newfs -r 4 -U /dev/md0 /dev/md0: 32.0MB (65532 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 8.00MB, 512 blks, 1024 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 16544, 32928, 49312 radius# ll /dev/ufsid/ total 0 crw-r----- 1 root operator 0, 98 21 ÓÅÎ 22:01 4c98f1c148b0469b crw-r----- 1 root operator 0, 99 21 ÓÅÎ 22:01 4c98f1c978a6bb52 radius# glabel status Name Status Components ufsid/4c98f1c148b0469b N/A ada2d ufsid/4c98f1c978a6bb52 N/A ada3d
Responsible Changed From-To: freebsd-bugs->freebsd-geom Over to maintainer(s).
On Tue, Oct 05, 2010 at 02:39:54PM +0400, Gleb Smirnoff wrote: > Hello, Pawel! > > There is a PR from my colleague - kern/150858. Do you > see any side effects of such loosening the comparison? > Can this be committed? (CCing Konstantin) Yes, what we have now is lesser evil. If we drop size comparison then GEOM_LABEL can pick anything from ad0, ad0s1 and ad0s1a when you have file system on top of ad0s1a and all start at offset 0. Unfortunately UFS metadata is not designed for automatic discovery, so there is not much we can do here. -- Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am!
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>