On Sun, Jan 26, 2025 at 08:56:47PM +0100, Jonathan Krebs wrote:
> @Konstantin Belousov: Thank You for the fast and helpful explanation!
>
> but does a finished write request from a disk / lower geli layer mean, that
> the data arrived on stable storage (in which case BIO_FLUSH seems
&
On Fri, Jan 24, 2025 at 08:10:01PM +0100, Jonathan Krebs wrote:
> Dear FreeBSD developers,
>
> Inside a QEMU-VM, I inserted calls to g_print_bio in the first lines of
> sys/cam/ata/ata_da.c:adastrategy() and
> sys/dev/virtio/block/virtio_blk.c:vtblk_strategy() of a FreeBSD 14.2, and
> added an ima
On Sat, Jan 29, 2022 at 03:29:39PM +1100, pet...@freebsd.org wrote:
> I'm working on a GEOM Gate network client to better handle high-latency
> connections and have some questions regarding bio ordering assumptions
> (alternatively, how much should I be able to re-order bio requests without
> break
On Thu, May 19, 2016 at 01:57:53PM -0700, Alfred Perlstein wrote:
> OK, and why is thread0 needing Giant for so long?
[Below is my opinion]
It does not need Giant per se, it needs a work done to audit and turn it
off. Probably most high profile subsystem in the kernel still relying on
Giant is the
not true for last 5-6
years for our kernel in general, and for the VFS in particular.
>
> -Alfred
>
>
> On 5/19/16 3:56 AM, Konstantin Belousov wrote:
> > I propose to remove asserts
> > mtx_assert(&Giant, MA_NOTOWNED);
> > from the geom KPI.
I propose to remove asserts
mtx_assert(&Giant, MA_NOTOWNED);
from the geom KPI. The asserts do not serve any purposes, at least not
in the current kernel. They might provided some agenda in the 5.x days,
but now they only force filesystems to add cruft to satisfy GEOM KPI
requirem
On Thu, Dec 10, 2015 at 02:20:19PM +0200, Max Gurtovoy wrote:
> Hi all,
>
> I'm developing an iSER (iSCSI extensions for RDMA) driver for FreeBSD
> 11-Current and I encounter some weired behaviour while testing IOs with
> iovcnt > 1.
> I wrote a small test program that creates an iovec struct (l
On Mon, Mar 17, 2014 at 10:37:14PM -0400, Ryan Lortie wrote:
> hi,
>
> I'm part of a team that's trying to get the latest versions of GNOME
> (out of git) building on FreeBSD with the eventual goal of getting a
> "continuous integration" sort of setup so that we can flag FreeBSD
> portability issu
On Wed, Dec 04, 2013 at 06:07:43PM -0800, John-Mark Gurney wrote:
> Konstantin Belousov wrote this message on Wed, Dec 04, 2013 at 18:20 +0200:
> > On Wed, Dec 04, 2013 at 01:59:52PM +0100, Paolo Pinto wrote:
> > > Hi list!
> > >
> > > My kernel is compile
On Wed, Dec 04, 2013 at 01:59:52PM +0100, Paolo Pinto wrote:
> Hi list!
>
> My kernel is compiled with option INVARIANTS and I get a reproducible
> kernel panic when trying to read data from a GEOM based compressed
> memory disk:
>
> Unread portion of the kernel message buffer:
> panic: bio_lengt
On Mon, Apr 15, 2013 at 09:37:30PM +0200, Pawel Jakub Dawidek wrote:
> On Mon, Apr 15, 2013 at 10:18:15PM +0300, Konstantin Belousov wrote:
> > On Mon, Apr 15, 2013 at 08:42:03PM +0200, Pawel Jakub Dawidek wrote:
> > > On a mostly unrelated note when two threads (T0 and
On Mon, Apr 15, 2013 at 08:42:03PM +0200, Pawel Jakub Dawidek wrote:
> On a mostly unrelated note when two threads (T0 and T1) call get*time()
> on two different cores, but T0 does that a bit earlier is it possible
> that T0 can get later time than T1?
Define earlier first.
If you have taken suff
On Mon, Jan 21, 2013 at 09:26:49PM +0400, Andrey V. Elsukov wrote:
> On 19.01.2013 15:01, Lev Serebryakov wrote:
> > Hello, Freebsd-geom.
> >
> > Patches to build and install world without root access will hit tree
> > in near future, and I wonder is it possible to build complete NanoBSD
> > ima
.c
> > > +++ b/src/sys/geom/geom_dev.c
> > > @@ -497,7 +497,7 @@ g_dev_orphan(struct g_consumer *cp)
> > >
> > > /* Destroy the struct cdev *so we get no more requests */
> > > unit = dev2unit(dev);
> > > - destroy_dev(dev);
> > > +
On Mon, Jun 11, 2012 at 03:27:39PM -0700, Steven Haber wrote:
> > I do not understand what you are proposing. Could you, please, show
> > the patch ?
>
> ---
> src/sys/geom/geom_dev.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/sys/geom/geom_dev.c b/src/sys/ge
troy_dev_tq() holds the devmtx during the destroy and
> devfs
> >> uses this lock to take refs before calling into geom. To me it seems
> we
> >> should be able to protect the cdev with just the devmtx, provided
> >> consumers of d_close(), d_open(), etc. ref an
On Mon, Jun 11, 2012 at 10:19:07AM -0700, Steven Haber wrote:
> Hey FreeBSD devs,
>
> I hope this is the right forum for this. I haven't used the FreeBSD
> mailing lists before. I'm a relatively new hire at EMC Isilon. We are
> using FreeBSD 7.0 as the basis for our scale-out NAS product line. We
17 matches
Mail list logo
