| To: | Eric Sandeen <sandeen@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: Data type overflow in xfs_trans_unreserve_and_mod_sb |
| From: | Shailendra Tripathi <stripathi@xxxxxxxxx> |
| Date: | Mon, 25 Sep 2006 20:22:49 +0530 |
| Cc: | David Chinner <dgc@xxxxxxx>, xfs@xxxxxxxxxxx, Timothy Shimmin <tes@xxxxxxx> |
| In-reply-to: | <4517E88E.4020809@xxxxxxxxxxx> |
| References: | <55EF1E5D5804A542A6CA37E446DDC206655888@xxxxxxxxxxxxxxxxxxxxxx> <45179573.3020007@xxxxxxxxx> <4517E88E.4020809@xxxxxxxxxxx> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla Thunderbird 0.9 (X11/20041127) |
Eric Sandeen wrote: Hm, yep, just ASSERT(error == 0);I suppose this is the trickiness of canceling a transaction at some points... Yes, you are right. At the point where it is being applied, all the things can't be reverted back as XFS does not store the "before-image". However, typically in most of such cases, XFS goes ahead with shutting down the filesystem assuming these to be catastrophic or incorrigible errors requiring manual intervention. First thoughts, "long" won't help on 32 bit machines, perhaps this should be an explicitly-sized 64-bit type -Eric p.s. good to see agami's recently active participation on the list! |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Data type overflow in xfs_trans_unreserve_and_mod_sb, Eric Sandeen |
|---|---|
| Next by Date: | DMAPI problem on the cvs tree of (2.6.17) SGI-XFS CVS-2006-08-26, Paul Schutte |
| Previous by Thread: | Re: Data type overflow in xfs_trans_unreserve_and_mod_sb, Eric Sandeen |
| Next by Thread: | DMAPI problem on the cvs tree of (2.6.17) SGI-XFS CVS-2006-08-26, Paul Schutte |
| Indexes: | [Date] [Thread] [Top] [All Lists] |