Commit graph

7 commits

Author SHA1 Message Date
Nathan Scott
c31e887807 [XFS] Fix incorrect use of BMAPI_READ in unwritten extent handling
(luckily just cosmetic).

SGI-PV: 942232
SGI-Modid: xfs-linux-melb:xfs-kern:23718a

Signed-off-by: Nathan Scott <nathans@sgi.com>
2005-09-05 10:06:55 +10:00
Nathan Scott
d52b44d07a [XFS] Fix regression in transaction reserved-block accounting for direct
writes.

SGI-PV: 938145
SGI-Modid: xfs-linux:xfs-kern:23088a

Signed-off-by: Nathan Scott <nathans@sgi.com>
2005-09-02 16:41:32 +10:00
Nathan Scott
06d10dd9ca [XFS] Merge fixes into realtime quota code, since one/two reported, still
not enabled though.

SGI-PV: 938145
SGI-Modid: xfs-linux:xfs-kern:22900a

Signed-off-by: Nathan Scott <nathans@sgi.com>
2005-06-21 15:48:47 +10:00
Russell Cattelan
68d1498c3a [XFS] Fix a bug in xfs_iomap for extent handling of write cases
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: Russell Cattelan <cattelan@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>
2005-05-06 06:42:22 -07:00
Nathan Scott
f403b7f452 [XFS] Cleanup use of loff_t vs xfs_off_t in the core code.
SGI Modid: xfs-linux:xfs-kern:22378a

Signed-off-by: Nathan Scott <nathans@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>
2005-05-05 13:33:40 -07:00
Nathan Scott
24e17b5fb9 [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: Nathan Scott <nathans@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>
.
2005-05-05 13:33:20 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00