* Re: Delaylog
2010-09-14 19:06 ` Delaylog Arkadiusz Miskiewicz
@ 2010-09-14 19:20 ` Fabricio Archanjo
2010-09-14 20:03 ` Delaylog Stan Hoeppner
2010-09-14 23:23 ` Delaylog Christoph Hellwig
2 siblings, 0 replies; 5+ messages in thread
From: Fabricio Archanjo @ 2010-09-14 19:20 UTC (permalink / raw)
To: xfs
nicee..
Thanks Arkadiusz,
I thought there was another thing which i did'n know..
On Tue, Sep 14, 2010 at 4:06 PM, Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> On Tuesday 14 of September 2010, Fabricio Archanjo wrote:
>> Hey all,
>>
>> I just trying delaylog in my server that has a mysql database. When
>> i monted my /var/lib/mysql with delaylog option, it showed me:
>> "Enabling EXPERIMENTAL delayed logging feature - use at your own
>> risk". Ok, i know it's experimental, but what kind of problem could i
>> have using delaylog?
>
> ... and what problems in case of system hang or power loss when compared to
> nodelaylog mode?
>
> --
> Arkadiusz Miśkiewicz PLD/Linux Team
> arekm / maven.pl http://ftp.pld-linux.org/
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Delaylog
2010-09-14 19:06 ` Delaylog Arkadiusz Miskiewicz
2010-09-14 19:20 ` Delaylog Fabricio Archanjo
@ 2010-09-14 20:03 ` Stan Hoeppner
2010-09-14 21:32 ` Delaylog Fabricio Archanjo
2010-09-14 23:23 ` Delaylog Christoph Hellwig
2 siblings, 1 reply; 5+ messages in thread
From: Stan Hoeppner @ 2010-09-14 20:03 UTC (permalink / raw)
To: xfs
Arkadiusz Miskiewicz put forth on 9/14/2010 2:06 PM:
> On Tuesday 14 of September 2010, Fabricio Archanjo wrote:
>> Hey all,
>>
>> I just trying delaylog in my server that has a mysql database. When
>> i monted my /var/lib/mysql with delaylog option, it showed me:
>> "Enabling EXPERIMENTAL delayed logging feature - use at your own
>> risk". Ok, i know it's experimental, but what kind of problem could i
>> have using delaylog?
>
> ... and what problems in case of system hang or power loss when compared to
> nodelaylog mode?
This was covered in prior posts IIRC. Delaylog holds more write
transactions in memory in an effort to decrease the amount of disk I/O
and optimize write patterns. The more blocks waiting in the in memory
log, the more data will be lost due to power outage, controller/disk
failure, storage HBA/network failure (iSCSI/FC), kernel panics, etc.
Same failure modes as before, but with potentially greater loss of
data--unless there is an undiscovered bug that can wreck the entire
filesystem. ;) Which I believe is the reason for the "experimental"
boilerplate.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Delaylog
2010-09-14 20:03 ` Delaylog Stan Hoeppner
@ 2010-09-14 21:32 ` Fabricio Archanjo
0 siblings, 0 replies; 5+ messages in thread
From: Fabricio Archanjo @ 2010-09-14 21:32 UTC (permalink / raw)
To: xfs
When i changed to delaylog option my database performance increased,
so how i have 2 databases one master another slave, i can keep it. If
i have problem on my filesystem, i'll need to changed the slave to
master and recover my master.
Thanks all.
On Tue, Sep 14, 2010 at 5:03 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
> Arkadiusz Miskiewicz put forth on 9/14/2010 2:06 PM:
>> On Tuesday 14 of September 2010, Fabricio Archanjo wrote:
>>> Hey all,
>>>
>>> I just trying delaylog in my server that has a mysql database. When
>>> i monted my /var/lib/mysql with delaylog option, it showed me:
>>> "Enabling EXPERIMENTAL delayed logging feature - use at your own
>>> risk". Ok, i know it's experimental, but what kind of problem could i
>>> have using delaylog?
>>
>> ... and what problems in case of system hang or power loss when compared to
>> nodelaylog mode?
>
> This was covered in prior posts IIRC. Delaylog holds more write
> transactions in memory in an effort to decrease the amount of disk I/O
> and optimize write patterns. The more blocks waiting in the in memory
> log, the more data will be lost due to power outage, controller/disk
> failure, storage HBA/network failure (iSCSI/FC), kernel panics, etc.
>
> Same failure modes as before, but with potentially greater loss of
> data--unless there is an undiscovered bug that can wreck the entire
> filesystem. ;) Which I believe is the reason for the "experimental"
> boilerplate.
>
> --
> Stan
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Delaylog
2010-09-14 19:06 ` Delaylog Arkadiusz Miskiewicz
2010-09-14 19:20 ` Delaylog Fabricio Archanjo
2010-09-14 20:03 ` Delaylog Stan Hoeppner
@ 2010-09-14 23:23 ` Christoph Hellwig
2 siblings, 0 replies; 5+ messages in thread
From: Christoph Hellwig @ 2010-09-14 23:23 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: xfs
On Tue, Sep 14, 2010 at 09:06:24PM +0200, Arkadiusz Miskiewicz wrote:
> On Tuesday 14 of September 2010, Fabricio Archanjo wrote:
> > Hey all,
> >
> > I just trying delaylog in my server that has a mysql database. When
> > i monted my /var/lib/mysql with delaylog option, it showed me:
> > "Enabling EXPERIMENTAL delayed logging feature - use at your own
> > risk". Ok, i know it's experimental, but what kind of problem could i
> > have using delaylog?
Basically you could hit a race or lockup in the code under high stress
or unusual workloads. So far we just had one possible lockup under very
high dbench load.
> ... and what problems in case of system hang or power loss when compared to
> nodelaylog mode?
The same as with the old log code - if you crash recently written data
might be lost. Unless a really severe bugs shows up (in either the old
or new code) that only includes data since the last fsync/sync. The
quantitative difference is that a lot more metadata is now cached in
core, so on a crash you can lose more recently written but not synced
metadata.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 5+ messages in thread