Date: Mon, 23 Feb 2015 08:26:08 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 197876] sector size agreed with GEOM gate is not reflected in the block size of the device entry Message-ID: <bug-197876-8-HgM87oV5uu@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-197876-8@https.bugs.freebsd.org/bugzilla/> References: <bug-197876-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197876 --- Comment #1 from jau@iki.fi --- It seems that the same disparity between GEOM internal settings and what is shown by stat() applies to all GEOM device entries. It also seems that this odd behavior is rooted in the vnode attributes being left uninitialized. In addition to st_blksize being persistently 4k, st_size and st_blocks are not initialized at all. The information to fill in the latter two is anyhow properly stored in the mediasize field of the provider. The only reason st_blksize is reported as 4k is this line in the function vn_stat (see vfs_vnops.c) sb->st_blksize = max(PAGE_SIZE, vap->va_blocksize); The contents of the vattr structure seem to be largely only what gets filled in by vattr_null (see vfs_subr.c) Here just a couple of examples... (sleipnir:pts/1) 9:58 ~> pfstat /dev/ggate0 /dev/ggate0: st_dev: 1895890688 st_ino: 190 st_mode: 0x21a0 st_nlink: 1 st_uid: 0 st_gid: 5 st_rdev: 190 st_size: 0 st_blocks: 0 st_blksize: 4096 st_flags: 0x0 st_gen: 0 st_btim: 1970-01-01 01:59:59.000000000 st_mtim: 2015-02-23 10:00:14.989084901 st_ctim: 2015-02-23 10:00:14.989084901 st_atim: 2015-02-23 10:00:14.989084901 (sleipnir:pts/1) DING! ~> pfstat /dev/mirror/root /dev/mirror/root: st_dev: 1895890688 st_ino: 201 st_mode: 0x21a0 st_nlink: 1 st_uid: 0 st_gid: 5 st_rdev: 201 st_size: 0 st_blocks: 0 st_blksize: 4096 st_flags: 0x0 st_gen: 0 st_btim: 1970-01-01 01:59:59.000000000 st_mtim: 2015-02-23 09:20:16.130940000 st_ctim: 2015-02-23 09:20:16.130940000 st_atim: 2015-02-23 09:22:11.158069059 In fact I think this is now becoming mostly a case of finding the proper place to fill in the appropriate 'struct vattr' fields from the provider structure. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-197876-8-HgM87oV5uu>