| To: | L A Walsh <lkml@xxxxxxxxx> |
|---|---|
| Subject: | Re: XFS: how to NOT null files on fsck? |
| From: | Andi Kleen <ak@xxxxxx> |
| Date: | Wed, 04 Aug 2004 02:48:09 +0200 |
| Cc: | linux-kernel@xxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx, nathans@xxxxxxx |
| In-reply-to: | <410FDA19.9020805@xxxxxxxxx> (L. A. Walsh's message of "Tue, 03 Aug 2004 11:31:53 -0700") |
| References: | <200407050247.53743.norberto+linux-kernel@xxxxxxxxxxxx> <40EEC9DC.8080501@xxxxxxxxx> <20040729013049.GE800@frodo> <410FDA19.9020805@xxxxxxxxx> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (gnu/linux) |
L A Walsh <lkml@xxxxxxxxx> writes: > Now I know it takes a while before data may end up on disk and that it > may not go out to disk in an ordered fashion, but 2-3 days? This isn't > a case of a multi-extent file. My current fstab is only 1335 bytes long. > I doubt it has ever been more than 2. Is this perhaps on a laptop? Some scripts for laptop use configure insanely long data flush times to conserve HD spin time. Sometimes it is even completely turned off (laptop mode). The extent flush is dependent on the configured bdflush or pdflushd data timeouts. The truncate is independent from this because it is flushed with a different path. -Andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2, bugzilla-daemon |
|---|---|
| Next by Date: | xfs 1.3.1 patch for kernel 2.4.19?, Junfeng Yang |
| Previous by Thread: | TAKE 914153 - sync preallocations, Nathan Scott |
| Next by Thread: | Re: XFS: how to NOT null files on fsck?, L A Walsh |
| Indexes: | [Date] [Thread] [Top] [All Lists] |