On Mon, Jan 11, 2010 at 10:30 PM, Richard Elling
wrote:
> I misinterpreted the question. My answer assumes reads from the same file.
>
> AFAIK, there is no thread-level I/O scheduler in Solaris. ZFS uses a priority
> scheduler which is based on the type of I/O and there are some other
> resource m
On Mon, Jan 11, 2010 at 9:29 PM, bank kus wrote:
>> Then you're actually asking for a fair I/O scheduler.
>
> yes are we currently fair? any good documentation on the priority model as it
> exists today?
I doubt it, first come-first go is most common. The same holds for
memory as well.
Regards,
Then you're actually asking for a fair I/O scheduler.
Regards,
Andrey
On Mon, Jan 11, 2010 at 8:12 PM, bank kus wrote:
> I was asking from the starvatoin point of view to see if B can be starved by
> a long bust from A
> --
> This message posted from opensolaris.org
> ___
Per Posix there's no read ordering guarantees for a file with
concurrent non-exclusive readers. Use queue/locks in the application
if you need ordering like this.
Regards,
Andrey
On Mon, Jan 11, 2010 at 7:05 PM, bank kus wrote:
> As of 2009.06 what is the policy with reordering ZFS file reads
On Sun, Dec 6, 2009 at 8:11 PM, Anurag Agarwal wrote:
> Hi,
>
> My reading of write code of ZFS (zfs_write in zfs_vnops.c), is that all the
> writes in zfs are logged in the ZIL. And if that indeed is the case, then
IIRC, there is some upper limit (1MB?) on writes that go to ZIL, with
larger ones
FS snapshot (hope that's what send stream contains) has tx ids for
(at least) all non-free blocks, thus providing a history, kind of.
Should be helpful, imho.
Regards,
Andrey
On Wed, Sep 9, 2009 at 9:07 PM, Matthew Ahrens wrote:
> Unfortunately, I don't think that the send stream would help us
On Tue, Aug 18, 2009 at 10:57 PM, Kip Macy wrote:
> On Tue, Aug 18, 2009 at 03:01, Andrey Kuzmin
> wrote:
>> The patch itself seems to be "purely opportunistic" :), hence two questions:
>> 1. How does it impact prefetch efficiency?
>
> On my workloads it does
The patch itself seems to be "purely opportunistic" :), hence two questions:
1. How does it impact prefetch efficiency?
2. If it does impact prefetch significantly, is there any other, less
destructive, locking approach?
Regards,
Andrey
On Tue, Aug 18, 2009 at 2:52 AM, Kip Macy wrote:
> I have
> Date: Thu, 30 Jul 2009 16:09:22 -0600
> From: Neil Perrin
> To: Pawel Jakub Dawidek
> Cc: zfs-code at opensolaris.org
> Subject: Re: [zfs-code] Argument allocated on stack passed to taskq.
> Message-ID: <4A721A12.8070404 at Sun.COM>
> Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
>
Because trash/recycle bin is far more common desktop metaphor, and
user experience counts.
On 6/7/09, Richard Elling wrote:
> Andrey Kuzmin wrote:
>>> Date: Sun, 07 Jun 2009 21:12:10 +1200
>>> From: Ian Collins
>>> To: paco
>>> Cc: zfs-code at ope
> Date: Sun, 07 Jun 2009 21:12:10 +1200
> From: Ian Collins
> To: paco
> Cc: zfs-code at opensolaris.org
> Subject: Re: [zfs-code] recovery deleted files
> Message-ID: <4A2B846A.4080906 at ianshome.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> paco wrote:
> > hello,
> >
> >
On Thu, Nov 6, 2008 at 1:50 AM, Eric Sproul wrote:
> Ben Rockwood wrote:
>> This is troubling because it means one disk can go wonky and render your
>> storage system useless until someone can respond, and I'd imagine most
>> admins would "solve" the problem via reboot, a very poor solution.
>
> A
My apologies for the false alert on a perfectly valid construct.
Regards,
Andrey
On Sun, Sep 21, 2008 at 12:09 AM, Andrey Kuzmin
wrote:
> While browsing zfs/sys/dmu.h, I noticed a definition that I doubt will
> work as expected:
> 158 #define DMU_MAX_ACCESS (10<<20) /* 10MB
While browsing zfs/sys/dmu.h, I noticed a definition that I doubt will
work as expected:
158 #define DMU_MAX_ACCESS (10<<20) /* 10MB */
Regards,
Andrey
> -Original Message-
> From: Darren.Moffat at Sun.COM [mailto:Darren.Moffat at Sun.COM]
> Sent: Wednesday, March 19, 2008 5:40 PM
> To: andrey.v.kuzmin at gmail.com
> Cc: zfs-code at opensolaris.org
> Subject: Re: zfs-code Digest, Vol 22, Issue 3
>
>
> I think you have misunderstood what
> Message: 1
> Date: Mon, 17 Mar 2008 12:40:23 +
> From: Darren J Moffat
> Subject: [zfs-code] Property inheritance during dataset creation
> To: zfs-code at opensolaris.org
> Cc: zfs-crypto-discuss at opensolaris.org
> Message-ID: <47DE66B7.1080408 at Sun.COM>
> Content-Type: text/plain; form
16 matches
Mail list logo
