xfs: fixes for for-next

From: Dave Chinner <[email protected]>

While the verifier reoutines may return EFSBADCRC when a buffer ahs a bad CRC, we need to translate that to EFSCORRUPTED so that the higher layers treat the error appropriately and so we return a consistent error to userspace. This fixes a xfs/005 regression.

Signed-off-by Dave Chinner <[email protected]>

---
 fs/xfs/xfs_mount.c     |  3 +++
 fs/xfs/xfs_symlink.c   |  4 ++++
 fs/xfs/xfs_trans_buf.c | 11 +++++++++++
 3 files changed, 18 insertions(+)

fs/xfs/xfs_mount.c +3 -0

index f96c056..993cb19 100644
@@ -314,6 +314,9 @@ reread:
 		error = bp->b_error;
 		if (loud)
 			xfs_warn(mp, "SB validate failed with error %d.", error);
+		/* bad CRC means corrupted metadata */
+		if (error == EFSBADCRC)
+			error = EFSCORRUPTED;
 		goto release_buf;
 	}
 

fs/xfs/xfs_symlink.c +4 -0

index 14e58f2..5fda189 100644
@@ -80,6 +80,10 @@ xfs_readlink_bmap(
 		if (error) {
 			xfs_buf_ioerror_alert(bp, __func__);
 			xfs_buf_relse(bp);
+
+			/* bad CRC means corrupted metadata */
+			if (error == EFSBADCRC)
+				error = EFSCORRUPTED;
 			goto out;
 		}
 		byte_cnt = XFS_SYMLINK_BUF_SPACE(mp, byte_cnt);

fs/xfs/xfs_trans_buf.c +7 -0

index 647b6f1..b8eef05 100644
@@ -275,6 +275,10 @@ xfs_trans_read_buf_map(
 			XFS_BUF_UNDONE(bp);
 			xfs_buf_stale(bp);
 			xfs_buf_relse(bp);
+
+			/* bad CRC means corrupted metadata */
+			if (error == EFSBADCRC)
+				error = EFSCORRUPTED;
 			return error;
 		}
 #ifdef DEBUG

@@ -338,6 +342,9 @@ xfs_trans_read_buf_map(
 				if (tp->t_flags & XFS_TRANS_DIRTY)
 					xfs_force_shutdown(tp->t_mountp,
 							SHUTDOWN_META_IO_ERROR);
+				/* bad CRC means corrupted metadata */
+				if (error == EFSBADCRC)
+					error = EFSCORRUPTED;
 				return error;
 			}
 		}

Quoted 6 lines · Dave Chinner

From: Dave Chinner <[email protected]>

While the verifier reoutines may return EFSBADCRC when a buffer ahs a bad CRC, we need to translate that to EFSCORRUPTED so that the higher layers treat the error appropriately and so we return a consistent error to userspace. This fixes a xfs/005 regression.

Can you say a little more about the philosophy here?

xfs/005 regresses because it expects "structure needs cleaning"

So if we instead return our (icky) CRC error code, we get something else.

But it is truly a different root cause.

So the goal is to NEVER leak EFSBADCRC to userspace? Maybe a comment above that error definition would help document that.

And I'm bit worried that we'll leak more in the future if things changed, or if things got missed here. Everything you have here looks fine, but it's not obvious that every path has been caught; it seems a bit random.

I know we _just_ merged my "differentiator" patches, but I wonder if it would be better to add XFS_BSTATE_BADCRC to b_state or some other field, and go back to always assigning EFSCORRUPTED. What do you think?

When I wrote those I wasn't thinking about keeping it all internal to the filesystem.

Quoted 10 lines · Eric Sandeen

Quoted 6 lines · Dave Chinner

From: Dave Chinner <[email protected]>

While the verifier reoutines may return EFSBADCRC when a buffer ahs a bad CRC, we need to translate that to EFSCORRUPTED so that the higher layers treat the error appropriately and so we return a consistent error to userspace. This fixes a xfs/005 regression.

Can you say a little more about the philosophy here?

Quoted 8 lines

xfs/005 regresses because it expects "structure needs cleaning"

So if we instead return our (icky) CRC error code, we get something else.

But it is truly a different root cause.

So the goal is to NEVER leak EFSBADCRC to userspace? Maybe a comment above that error definition would help document that.

Not permanently. At the moment, none of the code handles it correctly, and the leak to userspace is just a symptom that tells us we got somethign wrong. We have plenty of places where we check for EFSCORRUPTED and do something special, but if we get EFSBADCRC instead it will do the wrong thing....

Quoted 3 lines

And I'm bit worried that we'll leak more in the future if things changed, or if things got missed here. Everything you have here looks fine, but it's not obvious that every path has been caught; it seems a bit random.

It's not random. It's buffer reads that matter, and I checked all the calls to xfs_buf_read, xfs_buf_read_map, xfs_trans_read_buf and xfs_trans_read_buf. There aren't any other read interfaces that use verifiers, and so nothing else can return EFSBADCRC. For the log recovery cases, the buffer reads don' use verifiers, and those that do won't return EFSBADCRC (e.g. inode buffers).

Quoted 3 lines

I know we _just_ merged my "differentiator" patches, but I wonder if it would be better to add XFS_BSTATE_BADCRC to b_state or some other field, and go back to always assigning EFSCORRUPTED. What do you think?

It's just the first layer of adding differentiating support. We've just put the mechanism in place to do the differentiation because we need it for *userspace functionality* before we need it for in-kernel functionality. We put it in the kernel because it has value to us developers to indicate what type of corruption error was detected in the dmesg output. We can't however, do everything at once, so for the moment the kernel code needs to translate it back to something the higher layers understand and treat correctly.

Quoted 2 lines

When I wrote those I wasn't thinking about keeping it all internal to the filesystem.

Only for the moment, until there's code in the kernel that makes it a meaningfully different error.

Quoted 54 lines · Dave Chinner

Quoted 10 lines · Eric Sandeen

Quoted 6 lines · Dave Chinner

From: Dave Chinner <[email protected]>

While the verifier reoutines may return EFSBADCRC when a buffer ahs a bad CRC, we need to translate that to EFSCORRUPTED so that the higher layers treat the error appropriately and so we return a consistent error to userspace. This fixes a xfs/005 regression.

Can you say a little more about the philosophy here?

Quoted 8 lines

xfs/005 regresses because it expects "structure needs cleaning"

So if we instead return our (icky) CRC error code, we get something else.

But it is truly a different root cause.

So the goal is to NEVER leak EFSBADCRC to userspace? Maybe a comment above that error definition would help document that.

Not permanently. At the moment, none of the code handles it correctly, and the leak to userspace is just a symptom that tells us we got somethign wrong. We have plenty of places where we check for EFSCORRUPTED and do something special, but if we get EFSBADCRC instead it will do the wrong thing....

Quoted 3 lines

And I'm bit worried that we'll leak more in the future if things changed, or if things got missed here. Everything you have here looks fine, but it's not obvious that every path has been caught; it seems a bit random.

It's not random. It's buffer reads that matter, and I checked all the calls to xfs_buf_read, xfs_buf_read_map, xfs_trans_read_buf and xfs_trans_read_buf. There aren't any other read interfaces that use verifiers, and so nothing else can return EFSBADCRC. For the log recovery cases, the buffer reads don' use verifiers, and those that do won't return EFSBADCRC (e.g. inode buffers).

Quoted 3 lines

I know we _just_ merged my "differentiator" patches, but I wonder if it would be better to add XFS_BSTATE_BADCRC to b_state or some other field, and go back to always assigning EFSCORRUPTED. What do you think?

It's just the first layer of adding differentiating support. We've just put the mechanism in place to do the differentiation because we need it for *userspace functionality* before we need it for in-kernel functionality. We put it in the kernel because it has value to us developers to indicate what type of corruption error was detected in the dmesg output. We can't however, do everything at once, so for the moment the kernel code needs to translate it back to something the higher layers understand and treat correctly.

Quoted 2 lines

When I wrote those I wasn't thinking about keeping it all internal to the filesystem.

Quoted 2 lines

Only for the moment, until there's code in the kernel that makes it a meaningfully different error.

Ok, thanks. Modulo Brian's question about other paths, what is here so far looks ok to me, then. A commit message that indicates that this is somewhat temporary might be in order?

From: Dave Chinner <[email protected]>

While the verifier reoutines may return EFSBADCRC when a buffer ahs a bad CRC, we need to translate that to EFSCORRUPTED so that the higher layers treat the error appropriately and so we return a consistent error to userspace. This fixes a xfs/005 regression.

Signed-off-by Dave Chinner <[email protected]>

---

 fs/xfs/xfs_mount.c     |  3 +++
 fs/xfs/xfs_symlink.c   |  4 ++++
 fs/xfs/xfs_trans_buf.c | 11 +++++++++++
 3 files changed, 18 insertions(+)

fs/xfs/xfs_mount.c +3 -0

index f96c056..993cb19 100644
@@ -314,6 +314,9 @@ reread:
 		error = bp->b_error;
 		if (loud)
 			xfs_warn(mp, "SB validate failed with error %d.", error);
+		/* bad CRC means corrupted metadata */
+		if (error == EFSBADCRC)
+			error = EFSCORRUPTED;
 		goto release_buf;
 	}
 

fs/xfs/xfs_symlink.c +4 -0

index 14e58f2..5fda189 100644
@@ -80,6 +80,10 @@ xfs_readlink_bmap(
 		if (error) {
 			xfs_buf_ioerror_alert(bp, __func__);
 			xfs_buf_relse(bp);
+
+			/* bad CRC means corrupted metadata */
+			if (error == EFSBADCRC)
+				error = EFSCORRUPTED;
 			goto out;
 		}
 		byte_cnt = XFS_SYMLINK_BUF_SPACE(mp, byte_cnt);

fs/xfs/xfs_trans_buf.c +11 -0

index 647b6f1..b8eef05 100644
@@ -275,6 +275,10 @@ xfs_trans_read_buf_map(
 			XFS_BUF_UNDONE(bp);
 			xfs_buf_stale(bp);
 			xfs_buf_relse(bp);
+
+			/* bad CRC means corrupted metadata */
+			if (error == EFSBADCRC)
+				error = EFSCORRUPTED;
 			return error;
 		}
 #ifdef DEBUG

@@ -338,6 +342,9 @@ xfs_trans_read_buf_map(
 				if (tp->t_flags & XFS_TRANS_DIRTY)
 					xfs_force_shutdown(tp->t_mountp,
 							SHUTDOWN_META_IO_ERROR);
+				/* bad CRC means corrupted metadata */
+				if (error == EFSBADCRC)
+					error = EFSCORRUPTED;
 				return error;
 			}
 		}

@@ -375,6 +382,10 @@ xfs_trans_read_buf_map(
 		if (tp->t_flags & XFS_TRANS_DIRTY)
 			xfs_force_shutdown(tp->t_mountp, SHUTDOWN_META_IO_ERROR);
 		xfs_buf_relse(bp);
+
+		/* bad CRC means corrupted metadata */
+		if (error == EFSBADCRC)
+			error = EFSCORRUPTED;
 		return error;
 	}
 #ifdef DEBUG

Signature · 6 lines

1.9.0

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Quoted 7 lines · Dave Chinner

From: Dave Chinner <[email protected]>

While the verifier reoutines may return EFSBADCRC when a buffer ahs a bad CRC, we need to translate that to EFSCORRUPTED so that the higher layers treat the error appropriately and so we return a consistent error to userspace. This fixes a xfs/005 regression.

Quoted 2 lines

Signed-off-by Dave Chinner <[email protected]>

---

This change looks Ok to me, but when I start looking through the users of bp->b_error, I see examples like xfs_dir3_data_read() being called in xfs_dir2_leaf_addname() where it looks like an error could bubble all the way up to xfs_vn_mknod() and its callers.

If the intent is to use EFSBADCRC as an internal-only error to differentiate corruption from crc failure, why not push this more closely to the boundaries that we have already defined? For example, we already convert positive errnos to negative at the internal/external boundaries. Could we convert those to use some kind of XFS_USERSPACE_ERROR(error) macro/helper that converts errors appropriately?

Another thought could be to reconsider whether we still need some of these extra warnings, as in the xfs_mount.c hunk below, now that we have the generic xfs_verifier_error() messaging. E.g., if we could remove those, perhaps we could snub out EFSBADCRC in or around the verifier after it makes a distinction.

Quoted 8 lines · Brian Foster

Quoted 7 lines · Dave Chinner

From: Dave Chinner <[email protected]>

While the verifier reoutines may return EFSBADCRC when a buffer ahs a bad CRC, we need to translate that to EFSCORRUPTED so that the higher layers treat the error appropriately and so we return a consistent error to userspace. This fixes a xfs/005 regression.

Quoted 7 lines

Quoted 2 lines

Signed-off-by Dave Chinner <[email protected]>

---

This change looks Ok to me, but when I start looking through the users of bp->b_error, I see examples like xfs_dir3_data_read() being called in xfs_dir2_leaf_addname() where it looks like an error could bubble all the way up to xfs_vn_mknod() and its callers.

Sure, but:

xfs_dir3_data_read
xfs_da_read_buf
xfs_trans_read_buf_map

Which means the patch prevents the EFSBADCRC leaking back out through that path because it converts it in xfs_trans_read_buf_map.

Quoted 7 lines

If the intent is to use EFSBADCRC as an internal-only error to differentiate corruption from crc failure, why not push this more closely to the boundaries that we have already defined? For example, we already convert positive errnos to negative at the internal/external boundaries. Could we convert those to use some kind of XFS_USERSPACE_ERROR(error) macro/helper that converts errors appropriately?

That doesn't solve the problem needing an error conversion layer in the first place. The long term goal is to remove the error conversions in XFS by converting the core code to the same error passing conventions as the rest of the kernel code. We manage to screw the negation up fairly regularly because it is convoluted and we cal into generic code that returns negative errors from the core that returns positive errors in lots of places. The conversion surface is just too large to manage sanely.

Quoted 5 lines

Another thought could be to reconsider whether we still need some of these extra warnings, as in the xfs_mount.c hunk below, now that we have the generic xfs_verifier_error() messaging. E.g., if we could remove those, perhaps we could snub out EFSBADCRC in or around the verifier after it makes a distinction.

Redundant errors aren't s significant problem. It's the lack of meaningful error messages that are much more of an issue. We get more meaningful error messages as a result of the EFSBADCRC changes that have been made, but for the moment that error simply means EFSCORRUPTED to the higher layers. Hence the translation back to EFSCORRUPTED at the (low) layers where the error no longer has a distinct meaning.

As we add more functionality, EFSBADCRC will become more meaningful and so get propagated higher into the kernel code. But for now, it should remain an error that doesn't escape the lower layers...

Cheers,

Dave.

Signature · 2 lines

Dave Chinner
[email protected]

Quoted 23 lines · Dave Chinner

Quoted 8 lines · Brian Foster

Quoted 7 lines · Dave Chinner

From: Dave Chinner <[email protected]>

While the verifier reoutines may return EFSBADCRC when a buffer ahs a bad CRC, we need to translate that to EFSCORRUPTED so that the higher layers treat the error appropriately and so we return a consistent error to userspace. This fixes a xfs/005 regression.

Quoted 7 lines

Quoted 2 lines

Signed-off-by Dave Chinner <[email protected]>

---

This change looks Ok to me, but when I start looking through the users of bp->b_error, I see examples like xfs_dir3_data_read() being called in xfs_dir2_leaf_addname() where it looks like an error could bubble all the way up to xfs_vn_mknod() and its callers.

Sure, but:

xfs_dir3_data_read
xfs_da_read_buf
xfs_trans_read_buf_map

Quoted 3 lines

Which means the patch prevents the EFSBADCRC leaking back out through that path because it converts it in xfs_trans_read_buf_map.

Ok, I see. FWIW, I was also trolling through some of the log recovery code and it appears that code uses b_ops for write verification purposes only (i.e., crc generation I suspect), correct?

Quoted 8 lines

Quoted 7 lines

If the intent is to use EFSBADCRC as an internal-only error to differentiate corruption from crc failure, why not push this more closely to the boundaries that we have already defined? For example, we already convert positive errnos to negative at the internal/external boundaries. Could we convert those to use some kind of XFS_USERSPACE_ERROR(error) macro/helper that converts errors appropriately?

Quoted 9 lines

That doesn't solve the problem needing an error conversion layer in the first place. The long term goal is to remove the error conversions in XFS by converting the core code to the same error passing conventions as the rest of the kernel code. We manage to screw the negation up fairly regularly because it is convoluted and we cal into generic code that returns negative errors from the core that returns positive errors in lots of places. The conversion surface is just too large to manage sanely.

Well it wasn't clear that the error conversion layer was a problem that itself needed solving, but fair enough. ;) If the objective is to move away from the positive/negative business to something more "kernel native," then building more infrastructure around that is probably not the way to go, unless that was actually part of the changeover strategy (e.g., if we happened to use something that conditionally negated error values to support incremental codepath conversions... as a semi-random thought).

Quoted 6 lines

Quoted 5 lines

Another thought could be to reconsider whether we still need some of these extra warnings, as in the xfs_mount.c hunk below, now that we have the generic xfs_verifier_error() messaging. E.g., if we could remove those, perhaps we could snub out EFSBADCRC in or around the verifier after it makes a distinction.

Quoted 8 lines

Redundant errors aren't s significant problem. It's the lack of meaningful error messages that are much more of an issue. We get more meaningful error messages as a result of the EFSBADCRC changes that have been made, but for the moment that error simply means EFSCORRUPTED to the higher layers. Hence the translation back to EFSCORRUPTED at the (low) layers where the error no longer has a distinct meaning.

Right, the purpose is not to solve the problem of redundant errors. Rather, if the only thing preventing the consolidation of the EFSBADCRC trap to a single hunk are redundant errors, then it wouldn't be a problem to remove those errors and push the EFSBADCRC trap into the generic code for the purpose of clarity.

Quoted 24 lines · Brian Foster

Quoted 23 lines · Dave Chinner

Quoted 8 lines · Brian Foster

Quoted 7 lines · Dave Chinner

From: Dave Chinner <[email protected]>

While the verifier reoutines may return EFSBADCRC when a buffer ahs a bad CRC, we need to translate that to EFSCORRUPTED so that the higher layers treat the error appropriately and so we return a consistent error to userspace. This fixes a xfs/005 regression.

Quoted 7 lines

Quoted 2 lines

Signed-off-by Dave Chinner <[email protected]>

---

This change looks Ok to me, but when I start looking through the users of bp->b_error, I see examples like xfs_dir3_data_read() being called in xfs_dir2_leaf_addname() where it looks like an error could bubble all the way up to xfs_vn_mknod() and its callers.

Sure, but:

xfs_dir3_data_read
xfs_da_read_buf
xfs_trans_read_buf_map

Quoted 7 lines

Quoted 3 lines

Which means the patch prevents the EFSBADCRC leaking back out through that path because it converts it in xfs_trans_read_buf_map.

Ok, I see. FWIW, I was also trolling through some of the log recovery code and it appears that code uses b_ops for write verification purposes only (i.e., crc generation I suspect), correct?

Yes.

Quoted 18 lines

Quoted 8 lines

Quoted 7 lines

If the intent is to use EFSBADCRC as an internal-only error to differentiate corruption from crc failure, why not push this more closely to the boundaries that we have already defined? For example, we already convert positive errnos to negative at the internal/external boundaries. Could we convert those to use some kind of XFS_USERSPACE_ERROR(error) macro/helper that converts errors appropriately?

Quoted 9 lines

That doesn't solve the problem needing an error conversion layer in the first place. The long term goal is to remove the error conversions in XFS by converting the core code to the same error passing conventions as the rest of the kernel code. We manage to screw the negation up fairly regularly because it is convoluted and we cal into generic code that returns negative errors from the core that returns positive errors in lots of places. The conversion surface is just too large to manage sanely.

Quoted 8 lines

Well it wasn't clear that the error conversion layer was a problem that itself needed solving, but fair enough. ;) If the objective is to move away from the positive/negative business to something more "kernel native," then building more infrastructure around that is probably not the way to go, unless that was actually part of the changeover strategy (e.g., if we happened to use something that conditionally negated error values to support incremental codepath conversions... as a semi-random thought).

I'm not sure there's any real benefit to adding infrastructure when doing the conversion. It's a lot of little changes involving pushing the conversion down from the top layers, combined with converting interfaces (e.g. bmapi) as they get exposed.

Some functions will be able to lose variables as the return becomes a tri-state value (e.g. the btree functions for looking up records); others will be able to use IS_ERR() for pointer returns, and so on. This will have a flow on effect on the code in the callers, and so it really comes down to spending the time to peel back each layer carefully.

It's a lot of work, hence the "long term goal" aspect of it. We've been talking about doing this cleanup for several years now, but it hasn't yet been done because it's going to take hundreds of patches to do... ;)

Quoted 15 lines

Quoted 6 lines

Quoted 5 lines

Another thought could be to reconsider whether we still need some of these extra warnings, as in the xfs_mount.c hunk below, now that we have the generic xfs_verifier_error() messaging. E.g., if we could remove those, perhaps we could snub out EFSBADCRC in or around the verifier after it makes a distinction.

Quoted 8 lines

Redundant errors aren't s significant problem. It's the lack of meaningful error messages that are much more of an issue. We get more meaningful error messages as a result of the EFSBADCRC changes that have been made, but for the moment that error simply means EFSCORRUPTED to the higher layers. Hence the translation back to EFSCORRUPTED at the (low) layers where the error no longer has a distinct meaning.

Quoted 5 lines

Right, the purpose is not to solve the problem of redundant errors. Rather, if the only thing preventing the consolidation of the EFSBADCRC trap to a single hunk are redundant errors, then it wouldn't be a problem to remove those errors and push the EFSBADCRC trap into the generic code for the purpose of clarity.

I don't see much point in trying to have a single trap for EFSBADCRC because the moment we want to handle one of those cases specially we are going to have to - as a first step - remove the single trap and push it outwards to all the places that need it like this patch does....

Cheers,

Dave.

Signature · 2 lines

Dave Chinner
[email protected]

From: Dave Chinner <[email protected]>

While the verifier reoutines may return EFSBADCRC when a buffer ahs a bad CRC, we need to translate that to EFSCORRUPTED so that the higher layers treat the error appropriately and so we return a consistent error to userspace. This fixes a xfs/005 regression.

Signed-off-by Dave Chinner <[email protected]>

---

 fs/xfs/xfs_mount.c     |  3 +++
 fs/xfs/xfs_symlink.c   |  4 ++++
 fs/xfs/xfs_trans_buf.c | 11 +++++++++++
 3 files changed, 18 insertions(+)

fs/xfs/xfs_mount.c +3 -0

index f96c056..993cb19 100644
@@ -314,6 +314,9 @@ reread:
 		error = bp->b_error;
 		if (loud)
 			xfs_warn(mp, "SB validate failed with error %d.", error);
+		/* bad CRC means corrupted metadata */
+		if (error == EFSBADCRC)
+			error = EFSCORRUPTED;
 		goto release_buf;
 	}
 

fs/xfs/xfs_symlink.c +4 -0

index 14e58f2..5fda189 100644
@@ -80,6 +80,10 @@ xfs_readlink_bmap(
 		if (error) {
 			xfs_buf_ioerror_alert(bp, __func__);
 			xfs_buf_relse(bp);
+
+			/* bad CRC means corrupted metadata */
+			if (error == EFSBADCRC)
+				error = EFSCORRUPTED;
 			goto out;
 		}
 		byte_cnt = XFS_SYMLINK_BUF_SPACE(mp, byte_cnt);

fs/xfs/xfs_trans_buf.c +11 -0

index 647b6f1..b8eef05 100644
@@ -275,6 +275,10 @@ xfs_trans_read_buf_map(
 			XFS_BUF_UNDONE(bp);
 			xfs_buf_stale(bp);
 			xfs_buf_relse(bp);
+
+			/* bad CRC means corrupted metadata */
+			if (error == EFSBADCRC)
+				error = EFSCORRUPTED;
 			return error;
 		}
 #ifdef DEBUG

@@ -338,6 +342,9 @@ xfs_trans_read_buf_map(
 				if (tp->t_flags & XFS_TRANS_DIRTY)
 					xfs_force_shutdown(tp->t_mountp,
 							SHUTDOWN_META_IO_ERROR);
+				/* bad CRC means corrupted metadata */
+				if (error == EFSBADCRC)
+					error = EFSCORRUPTED;
 				return error;
 			}
 		}

@@ -375,6 +382,10 @@ xfs_trans_read_buf_map(
 		if (tp->t_flags & XFS_TRANS_DIRTY)
 			xfs_force_shutdown(tp->t_mountp, SHUTDOWN_META_IO_ERROR);
 		xfs_buf_relse(bp);
+
+		/* bad CRC means corrupted metadata */
+		if (error == EFSBADCRC)
+			error = EFSCORRUPTED;
 		return error;
 	}
 #ifdef DEBUG

Signature · 6 lines

1.9.0

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs