Bug 150858 - [geom] [geom_label] [patch] glabel(8) is not compatible with newfs -r flag
Summary: [geom] [geom_label] [patch] glabel(8) is not compatible with newfs -r flag
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.1-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-22 13:00 UTC by Konstantin Kukushkin
Modified: 2018-01-03 05:13 UTC (History)
0 users

See Also:


Attachments
file.diff (674 bytes, patch)
2010-09-22 13:00 UTC, Konstantin Kukushkin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Kukushkin 2010-09-22 13:00:12 UTC
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
Comment 1 Alexander Best freebsd_committer 2010-09-22 13:14:52 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-geom

Over to maintainer(s).
Comment 2 Pawel Jakub Dawidek freebsd_committer 2010-10-05 15:46:01 UTC
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!
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:06 UTC
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