On Mar 30, 2011, at 9:53 AM, rozhuk...@gmail.com wrote:
> Hi!
>
> geom_redboot and geom_map
> ( http://my.ddteam.net/hg/BASE/file/783974ced979/head/sys/geom/geom_map.c -
> based on redboot)
>
> Do same things: allow access to memory blocks on cfi/spi flash like
> partitions on disk.
> Redboot
On May 23, 2011, at 3:55 AM, Andrey V. Elsukov wrote:
> Hi,
>
> Since after r221788 many people report about lost of access to their
> MBR partitions, i prepared new patch:
>
> http://people.freebsd.org/~ae/mbr_geometry.diff
>
> It removes from GEOM_PART_MBR constraints to alignmen
On May 23, 2011, at 10:50 AM, Andrey V. Elsukov wrote:
>
>> In any event, I'd be tempted to use a #define for 4096 like
>> MBR_MAX_SECTOR_SIZE.
>>
>> -msize = MIN(pp->mediasize / pp->sectorsize, UINT32_MAX);
>> +msize = MIN(pp->mediasize / pp->sectorsize, 2 * UINT32_MAX);
>>
>> Why this
On May 23, 2011, at 10:35 AM, Marcel Moolenaar wrote:
> I think we've had enough rushed and ill thought-out changes going
> in already and I can see that not aligning MBR partitions on a track
> boundary is potentially perceived as a PITA violation.
I can understand only generating MBRs on a trac
On May 24, 2011, at 10:35 AM, Marcel Moolenaar wrote:
>
> On May 23, 2011, at 11:43 PM, Andriy Gapon wrote:
>
>> on 23/05/2011 20:38 Warner Losh said the following:
>>>
>>> On May 23, 2011, at 10:35 AM, Marcel Moolenaar wrote:
>>>> I think we
On May 25, 2011, at 9:22 AM, Andriy Gapon wrote:
> on 24/05/2011 22:18 Andrey V. Elsukov said the following:
>> On 24.05.2011 22:12, Marcel Moolenaar wrote:
>>>
>>> On May 24, 2011, at 10:46 AM, Warner Losh wrote:
>>>>> All I'm saying: be careful
On May 25, 2011, at 9:12 AM, Andriy Gapon wrote:
> on 24/05/2011 21:12 Marcel Moolenaar said the following:
>> With respect to the creation:
>>
>> Since out synthesized geometry is not necessarily the same
>> as other OSes, we could opt to synthesize a geometry that
>> has a track size (= sector
On Jul 25, 2012, at 4:29 PM, Andriy Gapon wrote:
> BTW, I think that it would be nice if the GEOM work-processing could re-use
> the
> CAM model.
> That is, try to execute GEOM bio transformations in the original thread as
> much
> as possible, defer work to the GEOM thread as the last resort.
On Thu, May 19, 2016 at 4:56 AM, Konstantin Belousov
wrote:
> I propose to remove asserts
> mtx_assert(&Giant, MA_NOTOWNED);
> from the geom KPI.
I can't see any reason for the assertion in today's kernel.
I might split out the lock / unlock of giant around thread creation
since
On Thu, May 19, 2016 at 3:31 PM, Konstantin Belousov
wrote:
> 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
On Fri, Jul 8, 2016 at 6:19 AM, Dexuan Cui wrote:
> Hi, I have a FreeBSD virtual machine (VM) running on Hyper-V and I'm testing
> Hyper-V's Disk Online Resizing feature. The feature can expand or shrink the
> (virtual) disk capacity of a VM when the VM is running.
>
> There is an issue with gpa
On Tue, Sep 12, 2017 at 5:54 AM, Andriy Gapon wrote:
>
> At the moment all GEOM labels are spoilable in a sense that opening a
> provider
> in the write mode spoils GEOM labels that are attached as other consumers.
> The reason for that behavior is that the writer may modify the (meta-)data
> in
On Fri, Nov 24, 2017 at 3:30 AM, Andriy Gapon wrote:
>
> https://reviews.freebsd.org/D13224
>
> Anyone interested is welcome to join the review.
>
I think it's a really bad idea. It introduces a 'one-size-fits-all' notion
of QoS that seems misguided. It conflates a shorter timeout with don't
ret
On Fri, Nov 24, 2017 at 6:34 AM, Andriy Gapon wrote:
> On 24/11/2017 15:08, Warner Losh wrote:
> >
> >
> > On Fri, Nov 24, 2017 at 3:30 AM, Andriy Gapon > <mailto:a...@freebsd.org>> wrote:
> >
> >
> > https://reviews.freebs
On Fri, Nov 24, 2017 at 10:17 AM, Andriy Gapon wrote:
> On 24/11/2017 16:57, Scott Long wrote:
> >
> >
> >> On Nov 24, 2017, at 6:34 AM, Andriy Gapon wrote:
> >>
> >> On 24/11/2017 15:08, Warner Losh wrote:
> >>>
> >>>
On Fri, Nov 24, 2017 at 10:20 AM, Andriy Gapon wrote:
> On 24/11/2017 18:33, Warner Losh wrote:
> >
> >
> > On Fri, Nov 24, 2017 at 6:34 AM, Andriy Gapon > <mailto:a...@freebsd.org>> wrote:
> >
> > On 24/11/2017 15:08, Warner Losh wrote:
> >
On Sat, Nov 25, 2017 at 9:58 AM, Andriy Gapon wrote:
> On 25/11/2017 18:25, Warner Losh wrote:
> >
> >
> > On Fri, Nov 24, 2017 at 10:17 AM, Andriy Gapon > <mailto:a...@freebsd.org>> wrote:
> >
> > On 24/11/2017 16:57, Scott Long wrote:
> &g
On Sat, Nov 25, 2017 at 10:36 AM, Andriy Gapon wrote:
>
> Timestamp of the first error is Jun 16 10:40:18.
> Timestamp of the last error is Jun 16 10:40:27.
> So, it took additional 9 seconds to finally produce EIO.
> That disk is a part of a ZFS mirror. If the request was failed after the
> fir
On Sat, Nov 25, 2017 at 10:40 AM, Andriy Gapon wrote:
>
> Before anything else, I would like to say that I got an impression that we
> speak
> from so different angles that we either don't understand each other's
> words or,
> even worse, misinterpret them.
I understand what you are suggesting.
On Mon, Mar 12, 2018 at 7:17 AM, Andriy Gapon wrote:
>
> According to Poul-Henning (phk@), the principal author of GEOM, a GEOM
> class's
> access method was intended to be a light-weight operation involving mostly
> access counts. That is, it should be (have been) close in spirit to what
> g_ac
On Fri, Mar 23, 2018 at 3:30 AM, Poul-Henning Kamp
wrote:
>
> In message <5e416eb6-0e79-1419-f09a-eb747215d...@freebsd.org>, Andriy
> Gapon writes:
> >On 12/03/2018 20:07, Poul-Henning Kamp wrote:
> >> If we want to have an architectural sound way to do slow operations
> >> before any "u
On Fri, Mar 23, 2018 at 4:38 AM, Andriy Gapon wrote:
> On 12/03/2018 20:07, Poul-Henning Kamp wrote:
> > If we want to have an architectural sound way to do slow operations
> > before any "user-I/O" is initiated, the right way to do so is to
> > define new BIO_OPEN and BIO_CLOSE operation, and i
On Mar 27, 2018 7:09 AM, "Andriy Gapon" wrote:
On 23/03/2018 15:31, Warner Losh wrote:
>
>
> On Fri, Mar 23, 2018 at 4:38 AM, Andriy Gapon <mailto:a...@freebsd.org>> wrote:
>
> On 12/03/2018 20:07, Poul-Henning Kamp wrote:
> > If we want to ha
On Fri, Dec 27, 2019 at 10:53 AM Alexander Motin wrote:
> Hi,
>
> As I can see, gsched code was not really maintained for the last 10
> years since being added. It misses many GEOM features added later, such
> as direct dispatch, unmapped I/O, stripesize/stripeoffset, resize, etc.
> Even if som
So I spent some time looking at what BIO_ORDERED means in today's kernel
and flavored it with my indoctrination of the ordering guarantees with BIO
requests
from when I wrote the CAM I/O scheduler. it's kinda long, but spells out
what
BIO_ORDERED means, where it can come from and who depends on it
On Fri, Feb 18, 2022 at 1:57 PM Poul-Henning Kamp
wrote:
>
> Warner Losh writes:
>
> > The root of this problem, I think, is the following:
> > % man 9 bio
> > No manual entry for bio
> > I think I'll have to massage this email into an ap
26 matches
Mail list logo
