| To: | Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: XFS information leak during crash |
| From: | Nathan Scott <nathans@xxxxxxx> |
| Date: | Thu, 3 Nov 2005 11:38:01 +1100 |
| Cc: | Jan Kasprzak <kas@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <Pine.LNX.4.62.0511030116160.2023@xxxxxxxxxxxxxxxxxxxxxxxx>; from mikulas@xxxxxxxxxxxxxxxxxxxxxxxx on Thu, Nov 03, 2005 at 01:19:10AM +0100 |
| References: | <20051102212722.GC6759@xxxxxxxxxx> <20051103101107.O6239737@xxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.62.0511030116160.2023@xxxxxxxxxxxxxxxxxxxxxxxx> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.2.5i |
On Thu, Nov 03, 2005 at 01:19:10AM +0100, Mikulas Patocka wrote: > >> either). Does XFS support a something like ext3's "data=ordered" mount > >> option? > > > > No, it doesn't. > > BTW. Why does it sometimes overwrite files with zeros after crash and > journal replay then? I thought that this was because it tries to avoid > users seeing uninitialized data. No, thats kinda related but not the same issue, its more to do with a truncate (or open(O_TRUNC)) followed by buffered writes to an existing file, which some applications do, and how that interacts poorly with delayed allocation (nothing is "overwritten with zeroes", its actually just a "hole"). But I do intend to get _some_ work done today, so you can google for a more detailed answer there if you're interested. cheers. -- Nathan |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: XFS information leak during crash, Mikulas Patocka |
|---|---|
| Next by Date: | Re: XFS information leak during crash, Glen Overby |
| Previous by Thread: | Re: XFS information leak during crash, Mikulas Patocka |
| Next by Thread: | Re: XFS information leak during crash, Glen Overby |
| Indexes: | [Date] [Thread] [Top] [All Lists] |