- 14 7月, 2007 1 次提交
-
-
由 David Chinner 提交于
During delayed allocation extent conversion or unwritten extent conversion, we need to reserve some blocks for transactions reservations. We need to reserve these blocks in case a btree split occurs and we need to allocate some blocks. Unfortunately, we've only ever reserved the number of data blocks we are allocating, so in both the unwritten and delalloc case we can get ENOSPC to the transaction reservation. This is bad because in both cases we cannot report the failure to the writing application. The fix is two-fold: 1 - leverage the reserved block infrastructure XFS already has to reserve a small pool of blocks by default to allow specially marked transactions to dip into when we are at ENOSPC. Default setting is min(5%, 1024 blocks). 2 - convert critical transaction reservations to be allowed to dip into this pool. Spots changed are delalloc conversion, unwritten extent conversion and growing a filesystem at ENOSPC. This also allows growing the filesytsem to succeed at ENOSPC. SGI-PV: 964468 SGI-Modid: xfs-linux-melb:xfs-kern:28865a Signed-off-by: NDavid Chinner <dgc@sgi.com> Signed-off-by: NTim Shimmin <tes@sgi.com>
-
- 08 5月, 2007 2 次提交
-
-
由 Lachlan McIlroy 提交于
The problem that has been addressed is that of synchronising updates of the file size with writes that extend a file. Without the fix the update of a file's size, as a result of a write beyond eof, is independent of when the cached data is flushed to disk. Often the file size update would be written to the filesystem log before the data is flushed to disk. When a system crashes between these two events and the filesystem log is replayed on mount the file's size will be set but since the contents never made it to disk the file is full of holes. If some of the cached data was flushed to disk then it may just be a section of the file at the end that has holes. There are existing fixes to help alleviate this problem, particularly in the case where a file has been truncated, that force cached data to be flushed to disk when the file is closed. If the system crashes while the file(s) are still open then this flushing will never occur. The fix that we have implemented is to introduce a second file size, called the in-memory file size, that represents the current file size as viewed by the user. The existing file size, called the on-disk file size, is the one that get's written to the filesystem log and we only update it when it is safe to do so. When we write to a file beyond eof we only update the in- memory file size in the write operation. Later when the I/O operation, that flushes the cached data to disk completes, an I/O completion routine will update the on-disk file size. The on-disk file size will be updated to the maximum offset of the I/O or to the value of the in-memory file size if the I/O includes eof. SGI-PV: 958522 SGI-Modid: xfs-linux-melb:xfs-kern:28322a Signed-off-by: NLachlan McIlroy <lachlan@sgi.com> Signed-off-by: NDavid Chinner <dgc@sgi.com> Signed-off-by: NTim Shimmin <tes@sgi.com>
-
由 Eric Sandeen 提交于
NULL. Patch provided by Eric Sandeen. SGI-PV: 961693 SGI-Modid: xfs-linux-melb:xfs-kern:28199a Signed-off-by: NEric Sandeen <sandeen@sandeen.net> Signed-off-by: NLachlan McIlroy <lachlan@sgi.com> Signed-off-by: NTim Shimmin <tes@sgi.com>
-
- 10 2月, 2007 2 次提交
-
-
由 Eric Sandeen 提交于
xfs_mac.h and xfs_cap.h provide definitions and macros that aren't used anywhere in XFS at all. They are left-overs from "to be implement at some point in the future" functionality that Irix XFS has. If this functionality ever goes into Linux, it will be provided at a different layer, most likely through the security hooks in the kernel so we will never need this functionality in XFS. Patch provided by Eric Sandeen (sandeen@sandeen.net). SGI-PV: 960895 SGI-Modid: xfs-linux-melb:xfs-kern:28036a Signed-off-by: NEric Sandeen <sandeen@sandeen.net> Signed-off-by: NDavid Chinner <dgc@sgi.com> Signed-off-by: NTim Shimmin <tes@sgi.com>
-
由 Eric Sandeen 提交于
The firstblock argument to xfs_bmap_finish is not used by that function. Remove it and cleanup the code a bit. Patch provided by Eric Sandeen. SGI-PV: 960196 SGI-Modid: xfs-linux-melb:xfs-kern:28034a Signed-off-by: NEric Sandeen <sandeen@sandeen.net> Signed-off-by: NDavid Chinner <dgc@sgi.com> Signed-off-by: NTim Shimmin <tes@sgi.com>
-
- 28 9月, 2006 1 次提交
-
-
由 Nathan Scott 提交于
SGI-PV: 955302 SGI-Modid: xfs-linux-melb:xfs-kern:26802a Signed-off-by: NNathan Scott <nathans@sgi.com> Signed-off-by: NTim Shimmin <tes@sgi.com>
-
- 20 6月, 2006 1 次提交
-
-
由 Nathan Scott 提交于
pure bloat. SGI-PV: 952969 SGI-Modid: xfs-linux-melb:xfs-kern:26251a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 09 6月, 2006 1 次提交
-
-
由 Olaf Weber 提交于
the range spanned by modifications to the in-core extent map. Add XFS_BUNMAPI() and XFS_SWAP_EXTENTS() macros that call xfs_bunmapi() and xfs_swap_extents() via the ioops vector. Change all calls that may modify the in-core extent map for the data fork to go through the ioops vector. This allows a cache of extent map data to be kept in sync. SGI-PV: 947615 SGI-Modid: xfs-linux-melb:xfs-kern:209226a Signed-off-by: NOlaf Weber <olaf@sgi.com> Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 22 3月, 2006 1 次提交
-
-
由 Yingping Lu 提交于
the trace. SGI-PV: 948300 SGI-Modid: xfs-linux-melb:xfs-kern:208069a Signed-off-by: NYingping Lu <yingping@sgi.com> Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 11 1月, 2006 4 次提交
-
-
由 Nathan Scott 提交于
arguments. SGI-PV: 907752 SGI-Modid: xfs-linux-melb:xfs-kern:24901a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
由 Nathan Scott 提交于
sources. SGI-PV: 907752 SGI-Modid: xfs-linux-melb:xfs-kern:24659a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
由 Nathan Scott 提交于
well. Also provides a mechanism for inheriting this property from the parent directory for new files. SGI-PV: 945264 SGI-Modid: xfs-linux-melb:xfs-kern:24367a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
由 Nicolas Kaiser 提交于
Header included twice. Signed-off-by: NNicolas Kaiser <nikai@nikai.net> Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 02 11月, 2005 4 次提交
-
-
由 Eric Sandeen 提交于
SGI-PV: 943266 SGI-Modid: xfs-linux:xfs-kern:200996a Signed-off-by: NEric Sandeen <sandeen@sgi.com> Signed-off-by: NNathan Scott <nathans@sgi.com>
-
由 Eric Sandeen 提交于
SGI-PV: 943266 SGI-Modid: xfs-linux:xfs-kern:199750a Signed-off-by: NEric Sandeen <sandeen@sgi.com> Signed-off-by: NNathan Scott <nathans@sgi.com>
-
由 Nathan Scott 提交于
boilerplate. SGI-PV: 913862 SGI-Modid: xfs-linux:xfs-kern:23903a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
由 Nathan Scott 提交于
SGI-PV: 943122 SGI-Modid: xfs-linux:xfs-kern:23901a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 05 9月, 2005 1 次提交
-
-
由 Nathan Scott 提交于
(luckily just cosmetic). SGI-PV: 942232 SGI-Modid: xfs-linux-melb:xfs-kern:23718a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 02 9月, 2005 1 次提交
-
-
由 Nathan Scott 提交于
writes. SGI-PV: 938145 SGI-Modid: xfs-linux:xfs-kern:23088a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 21 6月, 2005 1 次提交
-
-
由 Nathan Scott 提交于
not enabled though. SGI-PV: 938145 SGI-Modid: xfs-linux:xfs-kern:22900a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 06 5月, 2005 3 次提交
-
-
由 Russell Cattelan 提交于
This may be the cause of several open PV's of incorrect delay flags being set and then tripping asserts. Do not return a delay alloc extent when the caller is asking to do a write. SGI Modid: xfs-linux:xfs-kern:189616a Signed-off-by: NRussell Cattelan <cattelan@sgi.com> Signed-off-by: NChristoph Hellwig <hch@sgi.com>
-
由 Nathan Scott 提交于
SGI Modid: xfs-linux:xfs-kern:22378a Signed-off-by: NNathan Scott <nathans@sgi.com> Signed-off-by: NChristoph Hellwig <hch@sgi.com>
-
由 Nathan Scott 提交于
[XFS] Use the right offset when ensuring a delayed allocate conversion has covered the offset originally requested. Can cause data corruption when multiple processes are performing writeout on different areas of the same file. Quite difficult to hit though. SGI Modid: xfs-linux:xfs-kern:22377a Signed-off-by: NNathan Scott <nathans@sgi.com> Signed-off-by: NChristoph Hellwig <hch@sgi.com> .
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-