| 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@sandeen.net> |
| References: | <55EF1E5D5804A542A6CA37E446DDC206655888@mapibe17.exchange.xchg> <45179573.3020007@agami.com> <4517E88E.4020809@sandeen.net> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla Thunderbird 0.9 (X11/20041127) |
|
Eric Sandeen wrote: Hm, yep, just ASSERT(error == 0); 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 |
| <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] |