Messages in this thread | | | From | Tong Zhang <> | Date | Tue, 3 Nov 2020 08:52:32 -0500 | Subject | Re: [PATCH v3] qnx4: qnx4_block_map error handling |
| |
On Tue, Nov 3, 2020 at 5:54 AM David Laight <David.Laight@aculab.com> wrote: > > From: Tong Zhang > > Sent: 02 November 2020 23:14 > > > > qnx4_block_map() may return -EIO on funny qnx4 fs image, in this case do > > not interpret -EIO as a correct block number > > That commit message is now wrong. ouch -- what would you suggest here?
> Also 'blknum' is only 'unsigned long' so ~0ull is wrong. > It can be worth injecting an error and checking the error > propagation works. > > What is the actual maximum file size? The maximum file size is 2GB-1, but from my understanding qnx4_block_map() returns a physical block number. The max disk size supported is 2**64 bytes, however it is limited to unsigned long (2**32) -- so I am actually very hesitant to encode an error code in the return value without changing the function return type, which will introduce more changes I don't like. The original -EIO in qnx4_block_map() is also dodgy btw. > Is there actually an 'out of range' blknum value > that can be used to signify an error without > changing the return value to 'long long'. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) >
| |