[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a125a870910270829u794853c4x370d2bae86499de4@mail.gmail.com>
Date: Tue, 27 Oct 2009 16:29:12 +0100
From: Fredrik Andersson <nablaman@...il.com>
To: Eric Sandeen <sandeen@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: Fwd: Ext4 bug with fallocate
> To try to emulate, how does it write into the preallocated space; large or
> small IOs? Sequential streaming? mmap writes? It may not be relevant but
> would be nice to try to match it as closely as possible.
This is a big file that is written sequentially using stdio buffered
I/O (with a setvbuf of about 4K) in the drdbmake process. No mmap.
It is regenerated from an earlier version of the same file, and we
preallocate a file that is 25% bigger than the
previous version, to allow for more data than was in the previous file
and to utilize the extent concept in ext4.
We then read the previous file sequentially, update some entries here
and there and
rewrite it sequentially into the new, fallocated file. There is one
single instance of random I/O: Once the whole new
file has been written, we seek back to the start to write a fixed-size
header. We then ftruncate the file to the proper size.
No process is concurrently reading from the file that is being
written. There is however another process, nodeserv,
that does random reads from the "previous" file (the one we're
sequentially reading in drdbmake).
The deadlock is always in the final ftruncate. It does not help to
close the file and reopen it again before the ftruncate call.
/Fredrik
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists