MaoXiaoyun
2011-Jul-13 12:33 UTC
[Xen-devel] Window VM hit blue screen when dom0 uses ext4 with extent enabled
Hi:
We met quite strange blue screen problem when recently shift our dom0 fs from
ext3 to
ext4. We have some IO stress test, that is in a Win2003 HVM, a process perform
file reading
and writing after the VM startup. In our dom0 host, we start totally 10 HVMS to
run the test.
Here is the test result
1) if it is ext3 in dom0, test is ok
2) if it is ext4 in dom0, entent feature is disabled, test is ok.
3) if it is ext4 in dom0, and extent feature is enable, HVMs will got blue
screen one after another
in 15 -30 minutes. And the blue screen code implys something wrong with the
disk.
(Such as KERNEL_STACK_INPAGE_ERROR,
STOP 0x00000077(0x00000185,0x00000185,0x00000000,0x001FD000))
Also serial port has some log report:
(XEN) grant_table.c:578:d0 Iomem mapping not permitted ffffffffffffffff (domain
40)
(XEN) grant_table.c:578:d0 Iomem mapping not permitted ffffffffffffffff (domain
40)
When blue screen, I don''t see any abnormal log in messages.
It''s surprise me since
wi/wo extent make such big difference. We''ve been run VMs in ext3
quite a long time
with no failure, I also learnt that extent is a important feature in ext4,
couldn''t be wrong
so easily.
So what''s problem could it be ?
Any comments?
Thanks.
BTW: we have kernel 2.6.32.36 + xen 4.0.1
--_fd2e58f4-923c-4d1c-9d5e-81ad49f8b622_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit
<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:微软雅黑
}
--></style>
</head>
<body class=''hmmessage''><div
dir=''ltr''>
Hi:<BR>
<BR>
We met quite strange blue screen problem when recently
shift our dom0 fs from ext3 to<BR>
ext4. We have some IO stress test, that is in a Win2003 HVM, a process
perform file reading<BR>
and writing after the VM startup. In our dom0 host, we start totally
10 HVMS to run the test.<BR>
<BR>
Here is the test result<BR>
1) if it is ext3 in dom0, test is ok<BR>
2) if it is ext4 in dom0, entent feature is disabled, test is
ok.<BR>
3) if it is ext4 in dom0, and extent feature is enable, HVMs will got
blue screen one after another<BR>
in 15 -30 minutes. And the blue screen code implys something wrong
with the disk.<BR>
(Such as KERNEL_STACK_INPAGE_ERROR, <BR>
STOP 0x00000077(0x00000185,0x00000185,0x00000000,0x001FD000))<BR>
<BR>
Also serial port has some log report:<BR>
(XEN) grant_table.c:578:d0 Iomem mapping not permitted ffffffffffffffff (domain
40)<BR>(XEN) grant_table.c:578:d0 Iomem mapping not permitted
ffffffffffffffff (domain 40)<BR>
<BR>
When blue screen, I don''t see any abnormal log in
messages. It''s surprise me since<BR>
wi/wo extent make such big difference. We''ve been run VMs in
ext3 quite a long time <BR>
with no failure, I also learnt that extent is a important feature in ext4,
couldn''t be wrong <BR>
so easily. <BR>
<BR>
So what''s problem could it be ?<BR>
Any comments?<BR>
Thanks.<BR>
<BR>
BTW: we have kernel 2.6.32.36 + xen 4.0.1<BR>
<BR> <BR> </div></body>
</html>
--_fd2e58f4-923c-4d1c-9d5e-81ad49f8b622_--
--===============1687803380=Content-Type: text/plain;
charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
--===============1687803380==--
MaoXiaoyun
2011-Jul-14 05:44 UTC
[Xen-devel] RE: Window VM hit blue screen when dom0 uses ext4 with extent enabled
I think the 2.6.32.36 ext4 needs to backport this patch much likely. Otherwise it will hit the problem I met. http://patchwork.ozlabs.org/patch/79880/> > Message: 3 > Date: Wed, 13 Jul 2011 20:33:41 +0800 > From: MaoXiaoyun <tinnycloud@hotmail.com> > Subject: [Xen-devel] Window VM hit blue screen when dom0 uses ext4 > with extent enabled > To: xen devel <xen-devel@lists.xensource.com> > Message-ID: <BLU157-w24C4DDC1B2F561B849C853DA470@phx.gbl> > Content-Type: text/plain; charset="gb2312" > > > Hi: > > We met quite strange blue screen problem when recently shift our dom0 fs from ext3 to > ext4. We have some IO stress test, that is in a Win2003 HVM, a process perform file reading > and writing after the VM startup. In our dom0 host, we start totally 10 HVMS to run the test. > > Here is the test result > 1) if it is ext3 in dom0, test is ok > 2) if it is ext4 in dom0, entent feature is disabled, test is ok. > 3) if it is ext4 in dom0, and extent feature is enable, HVMs will got blue screen one after another > in 15 -30 minutes. And the blue screen code implys something wrong with the disk. > (Such as KERNEL_STACK_INPAGE_ERROR, > STOP 0x00000077(0x00000185,0x00000185,0x00000000,0x001FD000)) > > Also serial port has some log report: > (XEN) grant_table.c:578:d0 Iomem mapping not permitted ffffffffffffffff (domain 40) > (XEN) grant_table.c:578:d0 Iomem mapping not permitted ffffffffffffffff (domain 40) > > When blue screen, I don''t see any abnormal log in messages. It''s surprise me since > wi/wo extent make such big difference. We''ve been run VMs in ext3 quite a long time > with no failure, I also learnt that extent is a important feature in ext4, couldn''t be wrong > so easily. > > So what''s problem could it be ? > Any comments? > Thanks. > > BTW: we have kernel 2.6.32.36 + xen 4.0.1 > >--_0c8d3ba5-b81d-4ab7-bf1a-61ac0df2734c_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit <html> <head> <style><!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:微软雅黑 } --></style> </head> <body class=''hmmessage''><div dir=''ltr''> I think the 2.6.32.36 ext4 needs to backport this patch much likely.<BR> Otherwise it will hit the problem I met.<BR> <BR> <SPAN style="FONT-FAMILY: ''Calibri'',''sans-serif''; COLOR: #1f497d; FONT-SIZE: 10.5pt; mso-fareast-font-family: 宋体; mso-bidi-font-family: 宋体; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=EN-US><A href="http://patchwork.ozlabs.org/patch/79880/"><FONT color=#800080>http://patchwork.ozlabs.org/patch/79880/</FONT></A></SPAN><BR> <SPAN style="FONT-FAMILY: ''Calibri'',''sans-serif''; COLOR: #1f497d; FONT-SIZE: 10.5pt; mso-fareast-font-family: 宋体; mso-bidi-font-family: 宋体; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=EN-US></SPAN><BR>> <BR>> Message: 3<BR>> Date: Wed, 13 Jul 2011 20:33:41 +0800<BR>> From: MaoXiaoyun <tinnycloud@hotmail.com><BR>> Subject: [Xen-devel] Window VM hit blue screen when dom0 uses ext4<BR>> with extent enabled<BR>> To: xen devel <xen-devel@lists.xensource.com><BR>> Message-ID: <BLU157-w24C4DDC1B2F561B849C853DA470@phx.gbl><BR>> Content-Type: text/plain; charset="gb2312"<BR>> <BR>> <BR>> Hi:<BR>> <BR>> We met quite strange blue screen problem when recently shift our dom0 fs from ext3 to<BR>> ext4. We have some IO stress test, that is in a Win2003 HVM, a process perform file reading<BR>> and writing after the VM startup. In our dom0 host, we start totally 10 HVMS to run the test.<BR>> <BR>> Here is the test result<BR>> 1) if it is ext3 in dom0, test is ok<BR>> 2) if it is ext4 in dom0, entent feature is disabled, test is ok.<BR>> 3) if it is ext4 in dom0, and extent feature is enable, HVMs will got blue screen one after another<BR>> in 15 -30 minutes. And the blue screen code implys something wrong with the disk.<BR>> (Such as KERNEL_STACK_INPAGE_ERROR, <BR>> STOP 0x00000077(0x00000185,0x00000185,0x00000000,0x001FD000))<BR>> <BR>> Also serial port has some log report:<BR>> (XEN) grant_table.c:578:d0 Iomem mapping not permitted ffffffffffffffff (domain 40)<BR>> (XEN) grant_table.c:578:d0 Iomem mapping not permitted ffffffffffffffff (domain 40)<BR>> <BR>> When blue screen, I don''t see any abnormal log in messages. It''s surprise me since<BR>> wi/wo extent make such big difference. We''ve been run VMs in ext3 quite a long time <BR>> with no failure, I also learnt that extent is a important feature in ext4, couldn''t be wrong <BR>> so easily. <BR>> <BR>> So what''s problem could it be ?<BR>> Any comments?<BR>> Thanks.<BR>> <BR>> BTW: we have kernel 2.6.32.36 + xen 4.0.1<BR>> <BR>> <BR><BR> </div></body> </html> --_0c8d3ba5-b81d-4ab7-bf1a-61ac0df2734c_-- --===============0938748760=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0938748760==--
Ian Campbell
2011-Jul-14 08:02 UTC
Re: [Xen-devel] RE: Window VM hit blue screen when dom0 uses ext4 with extent enabled
On Thu, 2011-07-14 at 06:44 +0100, MaoXiaoyun wrote:> I think the 2.6.32.36 ext4 needs to backport this patch much likely. > Otherwise it will hit the problem I met. > > http://patchwork.ozlabs.org/patch/79880/That version is still in state NEW but something appears to have been committed upstream as e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d: ext4: serialize unaligned asynchronous DIO ext4 has a data corruption case when doing non-block-aligned asynchronous direct IO into a sparse file, as demonstrated by xfstest 240. ... Seems like a reasonable enough thing to backport to me (for what that''s worth). Although: It is also quite a lot slower (14 min for package installs, vs. 8 min for well-aligned) but I''ll take slow correctness over fast corruption any day. Mingming suggested that we can track outstanding conversions, and wait on those so that non-sparse files won''t be affected, and I''ve implemented that here; unaligned AIO to nonsparse files won''t take a perf hit. Something to bear in mind if you are deploying anything based on sparse files on ext4. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
MaoXiaoyun
2011-Jul-14 08:41 UTC
RE: [Xen-devel] RE: Window VM hit blue screen when dom0 uses ext4 with extent enabled
> Subject: Re: [Xen-devel] RE: Window VM hit blue screen when dom0 uses ext4 with extent enabled > From: Ian.Campbell@citrix.com > To: tinnycloud@hotmail.com > CC: xen-devel@lists.xensource.com; jeremy@goop.org; konrad.wilk@oracle.com > Date: Thu, 14 Jul 2011 09:02:06 +0100 > > On Thu, 2011-07-14 at 06:44 +0100, MaoXiaoyun wrote: > > I think the 2.6.32.36 ext4 needs to backport this patch much likely. > > Otherwise it will hit the problem I met. > > > > http://patchwork.ozlabs.org/patch/79880/ > > That version is still in state NEW but something appears to have been > committed upstream as e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d: > > ext4: serialize unaligned asynchronous DIO > > ext4 has a data corruption case when doing non-block-aligned > asynchronous direct IO into a sparse file, as demonstrated > by xfstest 240. > > ... > > Seems like a reasonable enough thing to backport to me (for what that''s > worth). Although: > It is also quite a lot slower > (14 min for package installs, vs. 8 min for well-aligned) > but I''ll take slow correctness over fast corruption any day. > > Mingming suggested that we can track outstanding > conversions, and wait on those so that non-sparse > files won''t be affected, and I''ve implemented that here; > unaligned AIO to nonsparse files won''t take a perf hit. > > Something to bear in mind if you are deploying anything based on sparse > files on ext4. >That''s right. Since we use VHD as our base image. We are trying to backport this patch, but isn''t easy for me. Meanwhile, there are quite a lot ext4 patches in upstream, I''m afried some of them are also needed for stable ext4, well, not sure. Could someone kindly backport e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d for me? Many thanks.> Ian. > > >--_06158c24-e5f0-401f-a0f2-49f23ad9cdb4_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit <html> <head> <style><!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:微软雅黑 } --></style> </head> <body class=''hmmessage''><div dir=''ltr''> <BR> <BR> <DIV>> Subject: Re: [Xen-devel] RE: Window VM hit blue screen when dom0 uses ext4 with extent enabled<BR>> From: Ian.Campbell@citrix.com<BR>> To: tinnycloud@hotmail.com<BR>> CC: xen-devel@lists.xensource.com; jeremy@goop.org; <A href="mailto:konrad.wilk@oracle.com">konrad.wilk@oracle.com</A><BR>> Date: Thu, 14 Jul 2011 09:02:06 +0100<BR>> <BR>> On Thu, 2011-07-14 at 06:44 +0100, MaoXiaoyun wrote:<BR>> > I think the 2.6.32.36 ext4 needs to backport this patch much likely.<BR>> > Otherwise it will hit the problem I met.<BR>> > <BR>> > http://patchwork.ozlabs.org/patch/79880/<BR>> <BR>> That version is still in state NEW but something appears to have been<BR>> committed upstream as e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d:<BR>> <BR>> ext4: serialize unaligned asynchronous DIO<BR>> <BR>> ext4 has a data corruption case when doing non-block-aligned<BR>> asynchronous direct IO into a sparse file, as demonstrated<BR>> by xfstest 240.<BR>> <BR>> ...<BR>> <BR>> Seems like a reasonable enough thing to backport to me (for what that''s<BR>> worth). Although:<BR>> It is also quite a lot slower<BR>> (14 min for package installs, vs. 8 min for well-aligned)<BR>> but I''ll take slow correctness over fast corruption any day.<BR>> <BR>> Mingming suggested that we can track outstanding<BR>> conversions, and wait on those so that non-sparse<BR>> files won''t be affected, and I''ve implemented that here;<BR>> unaligned AIO to nonsparse files won''t take a perf hit.<BR>> <BR>> Something to bear in mind if you are deploying anything based on sparse<BR>> files on ext4.<BR>> </DIV> <DIV>That''s right. Since we use VHD as our base image. </DIV> <DIV>We are trying to backport this patch, but isn''t easy for me.</DIV> <DIV>Meanwhile, there are quite a lot ext4 patches in upstream, I''m afried </DIV> <DIV>some of them are also needed for stable ext4, well, not sure.</DIV> <DIV> </DIV> <DIV>Could someone kindly backport e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d</DIV> <DIV>for me? </DIV> <DIV> </DIV> <DIV>Many thanks.</DIV> <DIV><BR>> Ian.<BR>> <BR>> <BR>> <BR></DIV> </div></body> </html> --_06158c24-e5f0-401f-a0f2-49f23ad9cdb4_-- --===============1766176344=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1766176344==--
Ian Campbell
2011-Jul-14 09:14 UTC
RE: [Xen-devel] RE: Window VM hit blue screen when dom0 uses ext4 with extent enabled
On Thu, 2011-07-14 at 09:41 +0100, MaoXiaoyun wrote:> > > > Subject: Re: [Xen-devel] RE: Window VM hit blue screen when dom0 > uses ext4 with extent enabled > > From: Ian.Campbell@citrix.com > > To: tinnycloud@hotmail.com > > CC: xen-devel@lists.xensource.com; jeremy@goop.org; > konrad.wilk@oracle.com > > Date: Thu, 14 Jul 2011 09:02:06 +0100 > > > > On Thu, 2011-07-14 at 06:44 +0100, MaoXiaoyun wrote: > > > I think the 2.6.32.36 ext4 needs to backport this patch much > likely. > > > Otherwise it will hit the problem I met. > > > > > > http://patchwork.ozlabs.org/patch/79880/ > > > > That version is still in state NEW but something appears to have > been > > committed upstream as e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d: > > > > ext4: serialize unaligned asynchronous DIO > > > > ext4 has a data corruption case when doing non-block-aligned > > asynchronous direct IO into a sparse file, as demonstrated > > by xfstest 240. > > > > ... > > > > Seems like a reasonable enough thing to backport to me (for what > that''s > > worth). Although: > > It is also quite a lot slower > > (14 min for package installs, vs. 8 min for well-aligned) > > but I''ll take slow correctness over fast corruption any day. > > > > Mingming suggested that we can track outstanding > > conversions, and wait on those so that non-sparse > > files won''t be affected, and I''ve implemented that here; > > unaligned AIO to nonsparse files won''t take a perf hit. > > > > Something to bear in mind if you are deploying anything based on > sparse > > files on ext4. > > > That''s right. Since we use VHD as our base image. > We are trying to backport this patch, but isn''t easy for me. > Meanwhile, there are quite a lot ext4 patches in upstream, I''m afried > some of them are also needed for stable ext4, well, not sure. > > Could someone kindly backport e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d > for me?I think would be a good idea to ping the ext4 developers about this and suggest that this might be a candidate for an upstream stable backport. If not then it would be good to know why not instead of blindly taking it into our stable tree... Ian.> > Many thanks. > > > Ian. > > > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
MaoXiaoyun
2011-Jul-15 04:46 UTC
RE: [Xen-devel] RE: Window VM hit blue screen when dom0 uses ext4 with extent enabled
Just a reminder Below patch is also needed. http://thread.gmane.org/gmane.comp.file-systems.ext4/19659> Subject: RE: [Xen-devel] RE: Window VM hit blue screen when dom0 uses ext4 with extent enabled > From: Ian.Campbell@eu.citrix.com > To: tinnycloud@hotmail.com > CC: xen-devel@lists.xensource.com; jeremy@goop.org; konrad.wilk@oracle.com > Date: Thu, 14 Jul 2011 10:14:22 +0100 > > On Thu, 2011-07-14 at 09:41 +0100, MaoXiaoyun wrote: > > > > > > > Subject: Re: [Xen-devel] RE: Window VM hit blue screen when dom0 > > uses ext4 with extent enabled > > > From: Ian.Campbell@citrix.com > > > To: tinnycloud@hotmail.com > > > CC: xen-devel@lists.xensource.com; jeremy@goop.org; > > konrad.wilk@oracle.com > > > Date: Thu, 14 Jul 2011 09:02:06 +0100 > > > > > > On Thu, 2011-07-14 at 06:44 +0100, MaoXiaoyun wrote: > > > > I think the 2.6.32.36 ext4 needs to backport this patch much > > likely. > > > > Otherwise it will hit the problem I met. > > > > > > > > http://patchwork.ozlabs.org/patch/79880/ > > > > > > That version is still in state NEW but something appears to have > > been > > > committed upstream as e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d: > > > > > > ext4: serialize unaligned asynchronous DIO > > > > > > ext4 has a data corruption case when doing non-block-aligned > > > asynchronous direct IO into a sparse file, as demonstrated > > > by xfstest 240. > > > > > > ... > > > > > > Seems like a reasonable enough thing to backport to me (for what > > that''s > > > worth). Although: > > > It is also quite a lot slower > > > (14 min for package installs, vs. 8 min for well-aligned) > > > but I''ll take slow correctness over fast corruption any day. > > > > > > Mingming suggested that we can track outstanding > > > conversions, and wait on those so that non-sparse > > > files won''t be affected, and I''ve implemented that here; > > > unaligned AIO to nonsparse files won''t take a perf hit. > > > > > > Something to bear in mind if you are deploying anything based on > > sparse > > > files on ext4. > > > > > That''s right. Since we use VHD as our base image. > > We are trying to backport this patch, but isn''t easy for me. > > Meanwhile, there are quite a lot ext4 patches in upstream, I''m afried > > some of them are also needed for stable ext4, well, not sure. > > > > Could someone kindly backport e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d > > for me? > > I think would be a good idea to ping the ext4 developers about this and > suggest that this might be a candidate for an upstream stable backport. > If not then it would be good to know why not instead of blindly taking > it into our stable tree... > > Ian. > > > > > Many thanks. > > > > > Ian. > > > > > > > > > > > > >--_4b4809b6-702e-4708-be74-3c354cf1d4e8_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit <html> <head> <style><!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:微软雅黑 } --></style> </head> <body class=''hmmessage''><div dir=''ltr''> Just a reminder <BR> Below patch is also needed.<BR> <BR> <A href="http://thread.gmane.org/gmane.comp.file-systems.ext4/19659">http://thread.gmane.org/gmane.comp.file-systems.ext4/19659</A><BR> <BR> <DIV> > Subject: RE: [Xen-devel] RE: Window VM hit blue screen when dom0 uses ext4 with extent enabled<BR>> From: Ian.Campbell@eu.citrix.com<BR>> To: tinnycloud@hotmail.com<BR>> CC: xen-devel@lists.xensource.com; jeremy@goop.org; konrad.wilk@oracle.com<BR>> Date: Thu, 14 Jul 2011 10:14:22 +0100<BR>> <BR>> On Thu, 2011-07-14 at 09:41 +0100, MaoXiaoyun wrote:<BR>> > <BR>> > <BR>> > > Subject: Re: [Xen-devel] RE: Window VM hit blue screen when dom0<BR>> > uses ext4 with extent enabled<BR>> > > From: Ian.Campbell@citrix.com<BR>> > > To: tinnycloud@hotmail.com<BR>> > > CC: xen-devel@lists.xensource.com; jeremy@goop.org;<BR>> > konrad.wilk@oracle.com<BR>> > > Date: Thu, 14 Jul 2011 09:02:06 +0100<BR>> > > <BR>> > > On Thu, 2011-07-14 at 06:44 +0100, MaoXiaoyun wrote:<BR>> > > > I think the 2.6.32.36 ext4 needs to backport this patch much<BR>> > likely.<BR>> > > > Otherwise it will hit the problem I met.<BR>> > > > <BR>> > > > http://patchwork.ozlabs.org/patch/79880/<BR>> > > <BR>> > > That version is still in state NEW but something appears to have<BR>> > been<BR>> > > committed upstream as e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d:<BR>> > > <BR>> > > ext4: serialize unaligned asynchronous DIO<BR>> > > <BR>> > > ext4 has a data corruption case when doing non-block-aligned<BR>> > > asynchronous direct IO into a sparse file, as demonstrated<BR>> > > by xfstest 240.<BR>> > > <BR>> > > ...<BR>> > > <BR>> > > Seems like a reasonable enough thing to backport to me (for what<BR>> > that''s<BR>> > > worth). Although:<BR>> > > It is also quite a lot slower<BR>> > > (14 min for package installs, vs. 8 min for well-aligned)<BR>> > > but I''ll take slow correctness over fast corruption any day.<BR>> > > <BR>> > > Mingming suggested that we can track outstanding<BR>> > > conversions, and wait on those so that non-sparse<BR>> > > files won''t be affected, and I''ve implemented that here;<BR>> > > unaligned AIO to nonsparse files won''t take a perf hit.<BR>> > > <BR>> > > Something to bear in mind if you are deploying anything based on<BR>> > sparse<BR>> > > files on ext4.<BR>> > > <BR>> > That''s right. Since we use VHD as our base image. <BR>> > We are trying to backport this patch, but isn''t easy for me.<BR>> > Meanwhile, there are quite a lot ext4 patches in upstream, I''m afried <BR>> > some of them are also needed for stable ext4, well, not sure.<BR>> > <BR>> > Could someone kindly backport e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d<BR>> > for me? <BR>> <BR>> I think would be a good idea to ping the ext4 developers about this and<BR>> suggest that this might be a candidate for an upstream stable backport.<BR>> If not then it would be good to know why not instead of blindly taking<BR>> it into our stable tree...<BR>> <BR>> Ian.<BR>> <BR>> > <BR>> > Many thanks.<BR>> > <BR>> > > Ian.<BR>> > > <BR>> > > <BR>> > > <BR>> > <BR>> <BR>> <BR></DIV> </div></body> </html> --_4b4809b6-702e-4708-be74-3c354cf1d4e8_-- --===============0458689931=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0458689931==--