| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
SGI-PV: 955515
SGI-Modid: xfs-linux-melb:xfs-kern:26806a
Signed-off-by: Nathan Scott <nathans@sgi.com>
Signed-off-by: Tim Shimmin <tes@sgi.com>
|
|
|
|
|
|
|
|
|
|
| |
positives.
SGI-PV: 955502
SGI-Modid: xfs-linux-melb:xfs-kern:26805a
Signed-off-by: Nathan Scott <nathans@sgi.com>
Signed-off-by: Tim Shimmin <tes@sgi.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
made me look at this code (bug id #344). We only return with
XFS_ERROR(EINVAL) if mp->m_rtdev_targp is valid and pass it otherwise to
xfs_read_buf() where some function calls later it gets dereferenced by an
assert.
SGI-PV: 954266
SGI-Modid: xfs-linux-melb:xfs-kern:26363a
Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: Nathan Scott <nathans@sgi.com>
|
|
|
|
|
|
|
|
|
| |
pure bloat.
SGI-PV: 952969
SGI-Modid: xfs-linux-melb:xfs-kern:26251a
Signed-off-by: Nathan Scott <nathans@sgi.com>
|
|
|
|
|
|
|
|
|
| |
interface.
SGI-PV: 953338
SGI-Modid: xfs-linux-melb:xfs-kern:26103a
Signed-off-by: Nathan Scott <nathans@sgi.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: Olaf Weber <olaf@sgi.com>
Signed-off-by: Nathan Scott <nathans@sgi.com>
|
|
|
|
|
|
|
|
|
| |
fix. Noticed by Roger Willcocks.
SGI-PV: 949821
SGI-Modid: xfs-linux-melb:xfs-kern:25257a
Signed-off-by: Nathan Scott <nathans@sgi.com>
|
|
|
|
|
|
|
|
|
| |
boilerplate.
SGI-PV: 913862
SGI-Modid: xfs-linux:xfs-kern:23903a
Signed-off-by: Nathan Scott <nathans@sgi.com>
|
|
|
|
|
|
|
| |
SGI-PV: 943122
SGI-Modid: xfs-linux:xfs-kern:23901a
Signed-off-by: Nathan Scott <nathans@sgi.com>
|
|
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!
|