At 05:41pm on 2010 June 12, Sage Weil did write:
> This bug is new in 2.6.35-rc1 from a22285a6 (Btrfs: Integrate metadata
> reservation with start_transaction). Just sent a patch fixing this up to
> the list.
Thank you, patch works perfectly.
Jim
--
To unsubscribe from this list: send the line
On Mon, 31 May 2010 09:20:22 +0200 Andreas Philipp wrote:
> I did not succeed to compile a btrfs module via dkms from btrfs-unstable...
> For the exact error message, please see the make.log...
> /var/lib/dkms/btrfs/git/build/extent-tree.c:1699: error:
> ‘DISCARD_FL_BARRIER’ undeclared (first
On Sat, Jun 12, 2010 at 7:22 PM, David Brown wrote:
> On Sat, Jun 12, 2010 at 06:06:23PM -0500, C Anthony Risinger wrote:
>
>>> # btrfs subvolume create new_root
>>> # mv . new_root/old_root
>
>> can i at least get confirmation that the above is possible?
>
> I've had no problem with
>
> # btrfs
On Sat, Jun 12, 2010 at 06:06:23PM -0500, C Anthony Risinger wrote:
# btrfs subvolume create new_root
# mv . new_root/old_root
can i at least get confirmation that the above is possible?
I've had no problem with
# btrfs subvolume snapshot . new_root
# mkdir old_root
# mv * old_root
On Sat, Jun 12, 2010 at 12:24 AM, C Anthony Risinger wrote:
> On Wed, May 19, 2010 at 9:01 AM, C Anthony Risinger wrote:
>> ..
>> i need a way, programmatically and safely, to "move" the users
>> installation from the original subvolume into an isolated subvolume
>> ..
>> or to ge
The CLONE and CLONE_RANGE ioctls round up the range of extents being
cloned to the block size when the range to clone extends to the end of file
(this is always the case with CLONE). It was then using that offset when
extending the destination file's i_size. Fix this by not setting i_size
beyond
On Sat, 12 Jun 2010, Jim Ursetto wrote:
> Both `cp --reflink` and `bcp` sometimes round the file size up to the next
> 4k boundary, with the balance consisting of null bytes. At first glance
> this behavior occurs for source file size > 3916 bytes. I have tried this
> with stock btrfs from kernel
On Sat, Jun 12, 2010 at 10:40:53PM +0200, Clemens Eisserer wrote:
> Hi,
>
> Recently Amarok started to reject some of music files.
> Some files seem to be simply corrupted (mplayer is still able to play
> them), other have zero length.
>
> Btrfsck reports:
> root 5 inode 1371 errors 400
> found 4
Hi,
> have you taken any snapshots? you could pull them from there maybe.
No snapshots unfourtunatly.
I wonder what could have caused those filesystem errors.
The only "unusual" thing I did was to mount it with "compress", but
other than that - i didn't even stress it a lot.
> btrfsck is not ab
On Sat, Jun 12, 2010 at 3:40 PM, Clemens Eisserer wrote:
> Hi,
>
> Recently Amarok started to reject some of music files.
> Some files seem to be simply corrupted (mplayer is still able to play
> them), other have zero length.
>
> Btrfsck reports:
> root 5 inode 1371 errors 400
> found 42498768896
Hi,
Recently Amarok started to reject some of music files.
Some files seem to be simply corrupted (mplayer is still able to play
them), other have zero length.
Btrfsck reports:
root 5 inode 1371 errors 400
found 42498768896 bytes used err is 1
total csum bytes: 41015664
total tree bytes: 49872896
Resubmitting, as it doesn't seem to be upstream yet.
-
Remove EXPERIMENTAL flag from btrfs and also state that the disk format
has indeed been finalized.
Signed-off-by: Christian Kujau
diff --git a/Documentation/filesystems/btrfs.txt
b/Documentation/filesystems/btrfs.tx
Both `cp --reflink` and `bcp` sometimes round the file size up to the next
4k boundary, with the balance consisting of null bytes. At first glance
this behavior occurs for source file size > 3916 bytes. I have tried this
with stock btrfs from kernel 2.6.35-rc2 and 2.6.35-rc1 -- specifically,
Ubun
13 matches
Mail list logo
