Here are two other possible approaches to fix the issue in question without
disrupting special "sector after the last one" handling logic. One
patches DIOCGDELETE code to not accept requests clearly beyond the
provider's media boundary and the other one extends g_delete_data() to
convert bio_lengt
Hi, I came across a bug that possibly affects all versions of FreeBSD since
dawn of the GEOM. There seems to be off-by-one error in the g_io_check()
allowing requests that just past the boundary of the device to be accepted.
I was particularly looking at generating BIO_DELETE requests in the
userla
ich grave a significant
> performance increase.
>
> See: https://svnweb.freebsd.org/base?view=revision&revision=256956
>
>
> On Tue, 18 Apr 2017 at 23:17, Maxim Sobolev wrote:
>
>> Hi, I've got curious as to why running the build on my machine on top of
>> the R
Hi, I've got curious as to why running the build on my machine on top of
the RAID1 volume seems to prefer loading one of the drives for reading.
Digging into the code I found this:
prio += (G_RAID_SUBDISK_S_ACTIVE - sd->sd_state) << 16;
/* If disk head is precisely
Smells like a bug in the geom_part where it supposed to re-read the
partitions and update its internal structures. The reason why it works when
you open dev/da1 for writing is because the geom_part provider that is
attached to that disk is destroyed and created anew when you close the fd.
-Maxim
