| To: | xfs-oss <xfs@xxxxxxxxxxx> |
|---|---|
| Subject: | sync() in 2.6.38.5 |
| From: | Paul Anderson <pha@xxxxxxxxx> |
| Date: | Tue, 29 Nov 2011 14:17:26 -0500 |
| Dkim-signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=6L/KyP6pf9E6Gp5YbQ9ZWiTx8Y/RpUR7Z4qRg09EvzE=; b=NIHvb1Fe/n4R9B0vZXbFO/x5CG4b+IK50bIoZnHazbIfFgiZdOKPYSU7UCHz1d1/pz kE4kQBB8IyvdruftiIOT9730oxsnyXdE/d9uxoJ870YwAwAkI5O9cku3/Lrk9jiJ4Jzf IMPHqpKyxwPDjNvZFnMiabbzfxheUXMjvADWM= |
| Sender: | powool@xxxxxxxxx |
Hi all, 2.6.38.5 (x64 intel, in todays case a 40TiByte SAN volume) appears to have a bug whereby not all active metadata will be flushed even on a quiescent machine (one that has nonetheless in the past been under very high load). We have tried several variations of clean shutdowns, combined with for example the "echo 3 >/proc/sys/vm/drop_caches" trick to no avail - we still get lost files (well, 0 length files). We have several big servers scheduled to go down shortly, and I was wondering if there are other ideas besides just coping all recent data to another server. Thanks, Paul |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 1/5] [PATCH] xfs: fix attr2 vs large data fork assert, Christoph Hellwig |
|---|---|
| Next by Date: | Re: [PATCH 0/4] xfs fixes for Linux 3.2-rc3, Ben Myers |
| Previous by Thread: | xfsprogs 3.1.7 MIGRATED to testing, Debian testing watch |
| Next by Thread: | Re: sync() in 2.6.38.5, Joe Landman |
| Indexes: | [Date] [Thread] [Top] [All Lists] |