| To: | xfs-masters@xxxxxxxxxxx, yjf@xxxxxxxxxxxxx |
|---|---|
| Subject: | [xfs-masters] Re: xfs 1.3.1 patch for kernel 2.4.19? |
| From: | Steve Lord <lord@xxxxxxx> |
| Date: | Fri, 27 Aug 2004 15:44:22 -0500 |
| Cc: | Eric Sandeen <sandeen@xxxxxxx> |
| In-reply-to: | <Pine.GSO.4.44.0408271331300.23812-100000@elaine24.Stanford.EDU> |
| References: | <Pine.GSO.4.44.0408271331300.23812-100000@elaine24.Stanford.EDU> |
| Reply-to: | xfs-masters@xxxxxxxxxxx |
| Sender: | xfs-masters-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla Thunderbird 0.7.1 (X11/20040626) |
Junfeng Yang wrote: > say after all transactions in the log are replayed, the log space may be > reclaimed. if the log space reclaimation writes hit the persistent > storage earlier than the transaction replay writes, and a crash happens in > between, then we lose commited transactions in the log. so presumably > there should be some sync/barrier points in log replaying. my question > is, what's the syncing mechanism in xfs log replay > Look in xlog_do_recover: first it replays the log, then it flushes out any buffers on the filesystem, which will cause all the replayed metadata to hit disk. Then it updates the tail of the log - so the first transaction after the mount will move the tail of the log to after the recovery just replayed. Any crash before that transaction hits the disk should replay the whole thing again. Steve |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [xfs-masters] Re: xfs 1.3.1 patch for kernel 2.4.19?, Steve Lord |
|---|---|
| Next by Date: | [xfs-masters] Re[18]:For you., hiroshi |
| Previous by Thread: | [xfs-masters] Re: xfs 1.3.1 patch for kernel 2.4.19?, Steve Lord |
| Next by Thread: | [xfs-masters] Re[18]:For you., hiroshi |
| Indexes: | [Date] [Thread] [Top] [All Lists] |