| To: | David Chinner <dgc@xxxxxxx> |
|---|---|
| Subject: | Re: Review: fix null files exposure growing via truncate V2 |
| From: | Lachlan McIlroy <lachlan@xxxxxxx> |
| Date: | Tue, 24 Jul 2007 14:08:41 +1000 |
| Cc: | xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx> |
| In-reply-to: | <20070619063714.GP86004887@xxxxxxx> |
| References: | <20070619063714.GP86004887@xxxxxxx> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Thunderbird 2.0.0.4 (X11/20070604) |
Looks good to me. Thanks for fixing it Dave. David Chinner wrote: Test 140 fails due to the ftruncate() logging the new file size before any data that had previously been written had hit the disk. IOWs, it violates the data write/inode size update rule that fixes the null files problem. The fix here checks when growing the file as to whether it the disk inode size is different to the in memory size. If they are different, we have data that needs to be written to disk beyond the existing on disk EOF. Hence to maintain ordering we need to flush this data out before we log the changed file size. Version 2: o Only flush the range between the old on disk size and the current in memory size. Cheers, Dave. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: raid50 and 9TB volumes, David Chinner |
|---|---|
| Next by Date: | TAKE 967674 - hole not show when file is created with resvsp, Vlad Apostolov |
| Previous by Thread: | Re: 2.6.21.3 Oops (was Re: XFS internal error xfs_da_do_buf(2) at line 2087 of file fs/xfs/xfs_da_btree.c. Caller 0xc01b00bd), Christoph Lameter |
| Next by Thread: | TAKE 967674 - hole not show when file is created with resvsp, Vlad Apostolov |
| Indexes: | [Date] [Thread] [Top] [All Lists] |