On 13 January 2012 23:07, Liu Bo <liubo2...@cn.fujitsu.com> wrote:
> On 01/06/2012 02:02 AM, Maik Zumstrull wrote:
>> Hello list,
>>
>> I hit a funny BIOS bug the other day where the BIOS suddenly sets a
>> HPA on a random hard disk, leaving only the first 33 MB accessible.
>> That disk had one device of a multi-device btrfs on it in my case.
>> (With dm-crypt/LUKS in between, no partitioning or LVM.)
>>
>> The reason I'm writing to you is that btrfs apparently didn't care at
>> all. It didn't complain, and it certainly didn't consider "Uhm, maybe
>> I should stop writing to a file system that mostly doesn't exist
>> anymore." The only errors I saw in dmesg were from the lower block
>> device level: someone trying to read or write beyond the end of a
>> device. An error btrfs apparently didn't mind. It took me a while to
>> figure out what had happened, during which time btrfsck and the btrfs
>> kernel part worked together to pretty much totally trash the fs. (I'm
>> still trying a few things, but I'm not hopeful. Hold the default
>> backup rant, I can in fact recover anything that was on this from
>> elsewhere, I think.)
>>
>> So, I think during mount, btrfs should check the reported size of the
>> block device, and if it's significantly smaller than fs metadata
>> implies it must be, mount degraded or read-only or not at all. And
>> mostly, complain. Loudly.
>>
>
> I also notice this, when we "mkfs.btrfs" with a "-b fssize", if "fssize" is
> larger than dev size, it will not complain and get "beyond the end" errors.
>
> so maybe we limit the mkfs size:
>
> diff --git a/mkfs.c b/mkfs.c
> index e3ced19..3ac8525 100644
> --- a/mkfs.c
> +++ b/mkfs.c
> @@ -1282,6 +1282,8 @@ int main(int ac, char **av)
> ret = btrfs_prepare_device(fd, file, zero_end,
> &dev_block_count, &mixed);
> if (block_count == 0)
> block_count = dev_block_count;
> + if (block_count > dev_block_count);
> + block_count = dev_block_count;
> } else {
> ac = 0;
> file = av[optind++];
>
> thanks,
> liubo
It might be a better idea to error out at this point. If the user is
asking for a filesystem larger than what is possible on the device, I
think the mkfs should fail completely.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
