| To: | DS <xfs@xxxxxxxxxxxx> |
|---|---|
| Subject: | Re: is the flush-on-close-after-truncate still needed? |
| From: | Dave Chinner <david@xxxxxxxxxxxxx> |
| Date: | Fri, 27 Jun 2008 17:28:00 +1000 |
| Cc: | Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx |
| In-reply-to: | <20080627071312.GB15920@bob.dscon.sk> |
| Mail-followup-to: | DS <xfs@xxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx |
| References: | <4859415B.3000009@sandeen.net> <200806181049.07812.dchinner@agami.com> <20080626210904.GA15920@bob.dscon.sk> <486407EB.70703@sandeen.net> <20080627071312.GB15920@bob.dscon.sk> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.5.17+20080114 (2008-01-14) |
On Fri, Jun 27, 2008 at 09:13:12AM +0200, DS wrote: > Thanx for interest. > > There is no chance to change all scripts (too many customers and > thousands and thousands perl/php skripts). > > I think it isn't right way compiling own perl/php libs with needed changes on > open/fopen function. Overwriting files by truncating then first and then not fsync'ing the file is a sure way to lose data if the system crashes. That's an application bug, not a filesystem bug, because the filesystem is only doing what it is told to do. XFS is ensuring that lazy application writers are unlikely to lose data when they carelessly overwriting data. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: is the flush-on-close-after-truncate still needed?, DS |
|---|---|
| Next by Date: | [PATCH 2/6] Replace the XFS buf iodone semaphore with a completion, Dave Chinner |
| Previous by Thread: | Re: is the flush-on-close-after-truncate still needed?, DS |
| Next by Thread: | TAKE 981498 - Remove infinite loop from xfsidbg_xaildump, Lachlan McIlroy |
| Indexes: | [Date] [Thread] [Top] [All Lists] |