Alex Elsayed gmail.com> writes:
>
> Mike Fedyk mikefedyk.com> writes:
>
> >
> > On Fri, Feb 12, 2010 at 1:04 PM, Alex Elsayed gmail.com>
> wrote:
> > > I'm getting a rather nasty BUG when I try to mount this filesystem,
> > > _including_ when I specify -o ro. I'm unsure what caused it, but
On Tue, Feb 16, 2010 at 02:28:00PM -0500, jim owens wrote:
> Josef Bacik wrote:
>> On Wed, Feb 10, 2010 at 01:53:50PM -0500, jim owens wrote:
>>> +
>>> +static int btrfs_dio_hole_read(struct btrfs_diocb *diocb, u64 hole_len)
>>> +{
>>> + int err = 0;
>>> + diocb->umc.todo = hole_len;
>>> + wh
Josef Bacik wrote:
On Wed, Feb 10, 2010 at 01:53:50PM -0500, jim owens wrote:
+
+static int btrfs_dio_hole_read(struct btrfs_diocb *diocb, u64 hole_len)
+{
+ int err = 0;
+ diocb->umc.todo = hole_len;
+ while (diocb->umc.todo) {
+ struct bio_vec uv;
+
On Sun, Feb 14, 2010 at 7:39 AM, Goffredo Baroncelli wrote:
> Hi all,
>
> On Sunday 14 February 2010, Thomas Kupper wrote:
>> Hi Goffredo,
>>
>> Great work! It is indeed much easier to work with one tool instead with the
> many of them!
>>
>> > Usage:
>> > btrfs snapshot|-s [/]
>> >
Chris Mason wrote:
[ use i_mutex for reads? ]
But, we already need the code that btrfs_page_mkwrite uses. It should
be enough to wait for the ordered extents and have the extent range
locked.
You don't mean have the lock_extent active while I issue the
btrfs_wait_ordered_range as I found that
On Mon, Feb 15, 2010 at 02:18:15PM -0500, jim owens wrote:
> Chris Mason wrote:
> >Thanks to both Jim and Josef for their time on this one. More comments
> >below.
> >
> >On Sat, Feb 13, 2010 at 08:30:07PM -0500, jim owens wrote:
> >>Josef Bacik wrote:
> >>>On Wed, Feb 10, 2010 at 01:53:50PM -0500
On Mon, Feb 15, 2010 at 05:40:54PM -0500, jim owens wrote:
> Christoph Hellwig wrote:
> >On Mon, Feb 15, 2010 at 05:26:34PM -0500, jim owens wrote:
> >>My understanding is the current 4k drives normally operate in
> >>512 byte read/write access mode unless you set them to run
> >>as 4k only.
> >>
>
On Mon, Feb 15, 2010 at 07:16:51PM +0900, TARUISI Hiroaki wrote:
> That's good for you. :)
>
> It may be surprising that simple suspending causes disk error.
> I posted a simple patch jast a week ago, I hope it will be
> merged soon.
I have this in the .34 queue, thanks!
-chris
--
To unsubscribe
Hi,
I've an utterly broken btrfs that makes btrfsck and btrfs-debug-tree
(version 0.19) die with a core dump. Are you interested in this
filesystem? Unfortunely, it has a size of 1TB and contains the backups of
our customers. Hence, I can't publish it. How can we come together?
Core was generated
