On Feb 23, 2013, Alexandre Oliva <ol...@gnu.org> wrote:
> On Feb 22, 2013, Josef Bacik <jba...@fusionio.com> wrote:
>> So I understand what you are getting at, but I think you are doing it wrong.
>> If
>> we're calling with CHUNK_ALLOC_FORCE, but somebody has already started to
>> allocate with CHUNK_ALLOC_NO_FORCE, we'll reset the space_info->force_alloc
>> to
>> our original caller's CHUNK_ALLOC_FORCE.
> But that's ok, do_chunk_alloc will set space_info->force_alloc to
> CHUNK_ALLOC_NO_FORCE at the end, when it succeeds allocating, and then
> anyone else waiting on the mutex to try to allocate will load the
> NO_FORCE from space_info.
>> So we only really care about making sure a chunk is actually
>> allocated, instead of doing this flag shuffling we should just do
>> if (space_info->chunk_alloc) { spin_unlock(&space_info->lock);
>> wait_event(!space_info->chunk_alloc); return 0;
I looked a bit further into it. I think I this would work if we had a
wait_queue for space_info->chunk_alloc. We don't, so the mutex
interface is probably the best we can do.
OTOH, I found out we seem to get into an allocate spree when a large
file is being quickly created, such as when creating a ceph journal or
making a copy of a multi-GB file. I suppose btrfs is just trying to
allocate contiguous space for the file, but unfortunately there doesn't
seem to be a fallback for allocation failure: as soon as data allocation
fails and space_info is set as full, the large write fails and the
filesystem becomes full, without even trying to use non-contiguous
storage. Isn't that a bug?
I've also been trying to track down why, on a single-data filesystem,
(compressed?) data reads that fail because of bad blocks also spike the
CPU load and lock the file that failed to map in and the entire
filesystem, so that the only way to recover is to force a reboot.
Does this sound familiar to anyone?
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
--
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
