| To: | Russell Cattelan <cattelan@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: Might have found a bug... |
| From: | patl@xxxxxxxxxxxxxxx (Patrick J. LoPresti) |
| Date: | 12 May 2001 11:51:14 -0400 |
| Cc: | linux-xfs@xxxxxxxxxxx |
| Distribution: | local |
| In-reply-to: | <mit.lcs.mail.linux-xfs/3AFC1625.44E539C8@thebarn.com> |
| References: | <200105111625.f4BGP9u10062@oss.sgi.com> <a3AFC1625.44E539C8@thebarn.com> |
| Sender: | owner-linux-xfs@xxxxxxxxxxx |
| User-agent: | Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
Russell Cattelan <cattelan@xxxxxxxxxxx> writes: > XFS uses delayed allocation / delayed write by default any data > written immediacy before a crash probably won't be on disk, this is > known behavior and isn't considered a bug, it's a trade off. Is this true even if I call fsync() or fdatasync() on the file? I am wondering about this because some applications (e.g., qmail) create a temp file, call fsync() to flush it to stable storage, use rename() to "commit" the file to its final home. With XFS, is this a reliable way to update a file on disk, or not? - Pat |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | xfsdump gui, Michael Vanderford |
|---|---|
| Next by Date: | Re: Might have found a bug..., Russell Cattelan |
| Previous by Thread: | Re: Might have found a bug..., Steve Lord |
| Next by Thread: | Re: Might have found a bug..., Russell Cattelan |
| Indexes: | [Date] [Thread] [Top] [All Lists] |