On Mon, Sep 18, 2017 at 06:47:38PM +, Derrick McKee wrote:
> I am trying to figure out if a particular disk operation is reading from
> the same location in an image file.
The following trace event is fired when a BlockBackend (a drive) is
read:
# block/block-backend.c
blk_co_preadv(void
On 09/18/2017 02:47 PM, Derrick McKee wrote:
> Hi,
>
Hi Derrick;
> I am trying to figure out if a particular disk operation is reading from
> the same location in an image file. I am simulating a USB disk, and during
Which device handles the USB disk emulation? hw/usb/dev-storage.c?
("usb-st
On 2017-09-18 20:47, Derrick McKee wrote:
> Hi,
>
> I am trying to figure out if a particular disk operation is reading from
> the same location in an image file. I am simulating a USB disk, and during
> an operation the guest OS performs, I would like to know how many times the
> backing image f
Am 14.08.2014 um 22:53 hat Xingbo Wu geschrieben:
> >> >> The main trick of QED was to introduce a dirty flag, which allowed to
> >> >> call fdatasync() less often because it was okay for image metadata to
> >> >> become inconsistent. After a crash, you have to repair the image then.
> >> >>
> >> >
>> >> The main trick of QED was to introduce a dirty flag, which allowed to
>> >> call fdatasync() less often because it was okay for image metadata to
>> >> become inconsistent. After a crash, you have to repair the image then.
>> >>
>> >
>> > I'm very curious about this dirty flag trick. I was su
Am 14.08.2014 um 04:42 hat Xingbo Wu geschrieben:
> On Wed, Aug 13, 2014 at 5:04 PM, Xingbo Wu wrote:
> > On Wed, Aug 13, 2014 at 2:32 PM, Kevin Wolf wrote:
> >> Am 13.08.2014 um 18:38 hat Xingbo Wu geschrieben:
> >>> On Wed, Aug 13, 2014 at 11:54 AM, Kevin Wolf wrote:
> >>> > Am 12.08.2014 um 0
On Wed, Aug 13, 2014 at 5:04 PM, Xingbo Wu wrote:
> On Wed, Aug 13, 2014 at 2:32 PM, Kevin Wolf wrote:
>> Am 13.08.2014 um 18:38 hat Xingbo Wu geschrieben:
>>> On Wed, Aug 13, 2014 at 11:54 AM, Kevin Wolf wrote:
>>> > Am 12.08.2014 um 01:38 hat 吴兴博 geschrieben:
>>> >> Hello,
>>> >>
>>> >> The
On 08/13/2014 03:04 PM, Xingbo Wu wrote:
>>> I read several messages from this thread: "[RFC] qed: Add QEMU
>>> Enhanced Disk format". To my understanding, if the new format can be
>>> acceptable to the community:
>>> It needs to retain all the key features provided by qcow2,
>>> especially for
On Wed, Aug 13, 2014 at 2:32 PM, Kevin Wolf wrote:
> Am 13.08.2014 um 18:38 hat Xingbo Wu geschrieben:
>> On Wed, Aug 13, 2014 at 11:54 AM, Kevin Wolf wrote:
>> > Am 12.08.2014 um 01:38 hat 吴兴博 geschrieben:
>> >> Hello,
>> >>
>> >> The introduction in the wiki page present several advantages of
Am 13.08.2014 um 18:38 hat Xingbo Wu geschrieben:
> On Wed, Aug 13, 2014 at 11:54 AM, Kevin Wolf wrote:
> > Am 12.08.2014 um 01:38 hat 吴兴博 geschrieben:
> >> Hello,
> >>
> >> The introduction in the wiki page present several advantages of qcow2
> >> [1].
> >> But I'm a little confused. I really
On Wed, Aug 13, 2014 at 11:54 AM, Kevin Wolf wrote:
> Am 12.08.2014 um 01:38 hat 吴兴博 geschrieben:
>> Hello,
>>
>> The introduction in the wiki page present several advantages of qcow2 [1].
>> But I'm a little confused. I really appreciate if any one can give me some
>> help
>> on this :).
>>
>>
Am 12.08.2014 um 01:38 hat 吴兴博 geschrieben:
> Hello,
>
> The introduction in the wiki page present several advantages of qcow2 [1].
> But I'm a little confused. I really appreciate if any one can give me some
> help
> on this :).
>
> (1) Currently the raw format doesn't support COW. In other
Am 12.08.2014 um 17:30 hat Eric Blake geschrieben:
> On 08/12/2014 08:14 AM, 吴兴博 wrote:
> >>> However FVD seems to have been ignored by community.
> >>
> >> Care to give a pointer to a URL describing the FVD format?
> >>
> >> http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg00398.html
> >
On Tue, 08/12 12:22, Xingbo Wu wrote:
> On Tue, Aug 12, 2014 at 11:30 AM, Eric Blake wrote:
>
> > On 08/12/2014 08:14 AM, 吴兴博 wrote:
> > >>> However FVD seems to have been ignored by community.
> > >>
> > >> Care to give a pointer to a URL describing the FVD format?
> > >>
> > >> http://lists.non
On Tue, Aug 12, 2014 at 03:23:38PM -0400, Xingbo Wu wrote:
> would be very space efficient for distribution :).
> Would you consider replace xz with lz4? it has faster decompression speed
> (~500MB/s)[1] and client-side decompression would be made painless.
No. The main benefit of xz is it has a
On Tue, Aug 12, 2014 at 2:52 PM, Richard W.M. Jones
wrote:
> On Tue, Aug 12, 2014 at 07:46:30PM +0100, Daniel P. Berrange wrote:
> > Taking the compression feature - arguably the biggest benefit of that
> > is when you distribute disk images. eg if someone provides a root disk
> > image on a web
On Tue, Aug 12, 2014 at 07:46:30PM +0100, Daniel P. Berrange wrote:
> Taking the compression feature - arguably the biggest benefit of that
> is when you distribute disk images. eg if someone provides a root disk
> image on a web server, using compression in qcow2 can dramatically
> lower the downl
On Mon, Aug 11, 2014 at 07:38:50PM -0400, 吴兴博 wrote:
> Hello,
>
> The introduction in the wiki page present several advantages of qcow2
> [1]. But I'm a little confused. I really appreciate if any one can give me
> some help on this :).
>
> (1) Currently the raw format doesn't support COW. In
On Tue, Aug 12, 2014 at 08:07:55AM -0600, Eric Blake wrote:
> On 08/12/2014 07:45 AM, 吴兴博 wrote:
>
> [please don't top-post on technical lists]
>
> > Thanks for your information. It's really helpful.
> > I think adding a bitmap alongside the raw file ( or just within that file)
>
> Umm, how do y
On Tue, Aug 12, 2014 at 11:30 AM, Eric Blake wrote:
> On 08/12/2014 08:14 AM, 吴兴博 wrote:
> >>> However FVD seems to have been ignored by community.
> >>
> >> Care to give a pointer to a URL describing the FVD format?
> >>
> >> http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg00398.html
On 08/12/2014 08:14 AM, 吴兴博 wrote:
>>> However FVD seems to have been ignored by community.
>>
>> Care to give a pointer to a URL describing the FVD format?
>>
>> http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg00398.html
>
> This thread could be the clearest message on FVD.
That very
On Tue, Aug 12, 2014 at 10:07 AM, Eric Blake wrote:
> On 08/12/2014 07:45 AM, 吴兴博 wrote:
>
> [please don't top-post on technical lists]
>
> Sorry about that..
> > Thanks for your information. It's really helpful.
> > I think adding a bitmap alongside the raw file ( or just within that
> file)
>
On 08/12/2014 07:45 AM, 吴兴博 wrote:
[please don't top-post on technical lists]
> Thanks for your information. It's really helpful.
> I think adding a bitmap alongside the raw file ( or just within that file)
Umm, how do you propose to add a bitmap within a raw file? The moment
the file contains
Thanks for your information. It's really helpful.
I think adding a bitmap alongside the raw file ( or just within that file)
would be suffice to distinguish between present or in backing file.
The idea in FVD looks similar to 'addcow'---use bitmap but delegating
allocation to FS. However FVD seems
On 08/11/2014 05:38 PM, 吴兴博 wrote:
> Hello,
>
> The introduction in the wiki page present several advantages of qcow2
> [1]. But I'm a little confused. I really appreciate if any one can give me
> some help on this :).
>
> (1) Currently the raw format doesn't support COW. In other words, a raw
On Tue, 12 Aug 2014, Fam Zheng wrote:
> On Mon, 08/11 19:38, 吴兴博 wrote:
> > Hello,
> >
> > The introduction in the wiki page present several advantages of qcow2
> > [1]. But I'm a little confused. I really appreciate if any one can give me
> > some help on this :).
> >
> > (1) Currently the r
On Tue, 08/12 08:03, 吴兴博 wrote:
> I carefully read your reply and thought of it carefully. I'm sorry that
> when I said "I get it" I actually meant "I believe you" but not "I
> understand it".
> The problem would not come from cp or rsync -- It's not their fault. They
> just have no way to make it
I carefully read your reply and thought of it carefully. I'm sorry that
when I said "I get it" I actually meant "I believe you" but not "I
understand it".
The problem would not come from cp or rsync -- It's not their fault. They
just have no way to make it right.
The real reason of it would be that
On Tue, 08/12 06:46, 吴兴博 wrote:
> Hi Fam,
> It's glad to hear you,
> It is said in this post that "All files systems that support inodes
> (ext2/3/4, xfs, btfs, etc) support files with holes while creating the
> files..."
> [
> http://serverfault.com/questions/558761/best-linux-filesystem-for-spa
Hi Fam,
It's glad to hear you,
It is said in this post that "All files systems that support inodes
(ext2/3/4, xfs, btfs, etc) support files with holes while creating the
files..."
[
http://serverfault.com/questions/558761/best-linux-filesystem-for-sparse-files
]
I also heard this claim from othe
On Mon, 08/11 19:38, 吴兴博 wrote:
> Hello,
>
> The introduction in the wiki page present several advantages of qcow2
> [1]. But I'm a little confused. I really appreciate if any one can give me
> some help on this :).
>
> (1) Currently the raw format doesn't support COW. In other words, a raw
>
On Mon, May 26, 2014 at 01:53:57PM +0400, M.Kustova wrote:
> About fuzzer effectiveness. 'qemu-img' was set as the fuzzer target,
> so its commands under interest are any that modify or/and read an
> image. As first step, a tested command will be selected randomly or
> specified by user. After inve
On Tue, May 27, 2014 at 3:35 PM, Richard W.M. Jones wrote:
>
> A few years ago I suggested a way to use systemtap probes to do
> feedback-directed fuzz-testing:
>
> http://rwmj.wordpress.com/2010/11/22/half-baked-ideas-feedback-directed-fuzz-testing-of-filesystems/#content
>
> When I tried to impl
A few years ago I suggested a way to use systemtap probes to do
feedback-directed fuzz-testing:
http://rwmj.wordpress.com/2010/11/22/half-baked-ideas-feedback-directed-fuzz-testing-of-filesystems/#content
When I tried to implement it, it turned out to mainly uncover bugs in
systemtap :-/
Rich.
On Mon, May 26, 2014 at 01:53:57PM +0400, M.Kustova wrote:
> About fuzzer effectiveness. 'qemu-img' was set as the fuzzer target,
> so its commands under interest are any that modify or/and read an
> image. As first step, a tested command will be selected randomly or
> specified by user.
qemu-io w
Hello Kevin,
Thanks a lot for your feedback.
Your first guess is absolutely correct. For now, 'action' can be
freely interpret as an image block will be corrupted. It's possible,
that in the future this term will be extended to a set of fuzzing
rules necessary to corrupt some image block, e.g. not
On Mon, May 26, 2014 at 09:07:43AM +0400, M.Kustova wrote:
> Hello,
>
> My name is Maria and I'm a participant of the Outreach Program for Women.
> My project is fuzz testing of support of qcow2 image format.
>
> The project git:
> https://github.com/maxalab/qemu_fuzzer.git
>
> It's pubic, so w
Hi Maria,
Am 26.05.2014 um 07:07 hat M.Kustova geschrieben:
> My name is Maria and I'm a participant of the Outreach Program for Women.
> My project is fuzz testing of support of qcow2 image format.
>
> The project git:
> https://github.com/maxalab/qemu_fuzzer.git
>
> It's pubic, so welcome, ma
On Friday 18 November 2005 17:44, Brett Gyarfas wrote:
> Hello again,
> Does anyone have a disk image for the SPARC64 that they can link me to?
>
> Thanks,
> Brett
>
>
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/ma
39 matches
Mail list logo
