| To: | xfs@xxxxxxxxxxx |
|---|---|
| Subject: | Re: Slow delete |
| From: | Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> |
| Date: | Tue, 20 Jul 2010 12:09:05 -0500 |
| In-reply-to: | <201007201304.28490@xxxxxx> |
| References: | <AANLkTinPmhJRD3CDdsHtkLFzYd2jF9ee7gPqgO6XBSfl@xxxxxxxxxxxxxx> <201007121417.14097@xxxxxx> <1279565697.1855.136.camel@doink> <201007201304.28490@xxxxxx> |
| User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 |
Michael Monnerie put forth on 7/20/2010 6:04 AM: > Can someone guess the exact problems that can happen with delayed > transaction on a crash? The only real crash scenario difference, as I understand it, is that with delayed logging enabled you'll potentially lose more data due to crash as more is held memory resident with delayed logging enabled. The characteristics of the data loss are the same with and without this enabled, it's just potentially more severe with delayed logging enabled. If your systems are prone to power loss, hardware failures, or kernel panics, I'd not enable delayed logging. If your systems are rock solid, and you can benefit from the minor decrease in file fragmentation and the increase in mass file delete speed, then enable it. -- Stan |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Calculating swidth On A RAID6 Volume, Emmanuel Florac |
|---|---|
| Next by Date: | [XFS updates] XFS development tree branch, master, updated. v2.6.34-10103-g0fef16d, xfs |
| Previous by Thread: | Re: Slow delete, Michael Monnerie |
| Next by Thread: | Re: Slow delete, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |