Date: Sat, 21 Feb 2015 09:50:35 +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@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197876 Bug ID: 197876 Summary: sector size agreed with GEOM gate is not reflected in the block size of the device entry Product: Base System Version: 10.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: jau@iki.fi When I set a 16k sector size for a new GEOM gate provider the existing consumers happily use multiples of 16k when tasting the new provider. The sector size is not reflected in the block size of the new device entry as reported by stat(), though. The new device entry is reported as using 4k blocks by stat(). If I ignore the block size value reported by stat() and anyhow use what was set when the new provider was created, everything works. (dd bs=16384 ...) The big problem is that usually programs know nothing more of the true block size but what is reported by stat(). Think of e.g. stdio. Any program using stdio to access a device will end up trying to use a wrong block size. When the user space application (think of e.g. fstyp) tries to use wrong block size to read or write the new device, the request never gets all the way to GEOM gate. Something higher up in the chain notices that the block size used by the program does not match the sector size of the underlying GEOM provider and responds with EINVAL to the program. For the time being I do not know how and where the device entry gets the faulty block size. -- 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>