reflinked file size incorrect
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, Ubuntu 2.6.35-2.3~lucid1-server and 2.6.35-1.1~lucid1-server. Any ideas? $ rm -f abc; dd if=/dev/urandom of=abc bs=1 count=3917; \ cp --reflink abc abc.1; ll abc* 3917 bytes (3.9 kB) copied, 0.0380613 s, 103 kB/s -rw-r- 1 root root 3917 2010-06-12 04:22 abc -rw-r- 1 root root 4096 2010-06-12 04:22 abc.1 $ rm -f abc; dd if=/dev/urandom of=abc bs=1 count=3916; \ cp --reflink abc abc.1; ll abc* 3916 bytes (3.9 kB) copied, 0.0299729 s, 131 kB/s -rw-r- 1 root root 3916 2010-06-12 04:22 abc -rw-r- 1 root root 3916 2010-06-12 04:22 abc.1 $ rm -f abc; dd if=/dev/urandom of=abc bs=1 count=4097; \ cp --reflink abc abc.1; ll abc* 4097 bytes (4.1 kB) copied, 0.0258441 s, 159 kB/s -rw-r- 1 root root 4097 2010-06-12 11:08 abc -rw-r- 1 root root 8192 2010-06-12 11:08 abc.1 $ uname -a Linux allie 2.6.35-2-server #3~lucid1-Ubuntu SMP Thu Jun 10 17:52:32 UTC 2010 x86_64 GNU/Linux Jim -- 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
[PATCH] Remove EXPERIMENTAL flag from Btrfs
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 li...@nerdbynature.de diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index 64087c3..da67070 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -12,9 +12,9 @@ number of challenges with scaling to the large storage subsystems that are becoming common in today's data centers. Filesystems need to scale in their ability to address and manage large storage, and also in their ability to detect, repair and tolerate errors in the data stored -on disk. Btrfs is under heavy development, and is not suitable for -any uses other than benchmarking and review. The Btrfs disk format is -not yet finalized. +on disk. Btrfs is under heavy development, but with Linux 2.6.31 the +Btrfs disk format has been finalized and is not considered experimental +any more. The main Btrfs features include: @@ -33,6 +33,7 @@ The main Btrfs features include: * Efficient incremental backup and FS mirroring (not yet implemented) * Online filesystem defragmentation +Please see https://btrfs.wiki.kernel.org for details on these features. MAILING LIST diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig index 7bb3c02..cebb197 100644 --- a/fs/btrfs/Kconfig +++ b/fs/btrfs/Kconfig @@ -1,16 +1,12 @@ config BTRFS_FS - tristate Btrfs filesystem (EXPERIMENTAL) Unstable disk format - depends on EXPERIMENTAL + tristate Btrfs filesystem select LIBCRC32C select ZLIB_INFLATE select ZLIB_DEFLATE help Btrfs is a new filesystem with extents, writable snapshotting, - support for multiple devices and many more features. - - Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET - FINALIZED. You should say N here unless you are interested in - testing Btrfs with non-critical data. + support for multiple devices and many more features. For more + information, please see https://btrfs.wiki.kernel.org. To compile this file system support as a module, choose M here. The module will be called btrfs. -- BOFH excuse #186: permission denied -- 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
Music-files suddenly not recognized anymore, empty files - Btrfschk reports errors
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: 498728960 total fs tree bytes: 406466560 btree space waste bytes: 110792472 file data blocks allocated: 271306133504 referenced 46886879232 Btrfs Btrfs v0.19 Anything I can do to repair those errors? Thank you in advance, Clemens -- 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
Re: Music-files suddenly not recognized anymore, empty files - Btrfschk reports errors
On Sat, Jun 12, 2010 at 3:40 PM, Clemens Eisserer linuxhi...@gmail.com 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 bytes used err is 1 total csum bytes: 41015664 total tree bytes: 498728960 total fs tree bytes: 406466560 btree space waste bytes: 110792472 file data blocks allocated: 271306133504 referenced 46886879232 Btrfs Btrfs v0.19 Anything I can do to repair those errors? have you taken any snapshots? you could pull them from there maybe. btrfsck is not able to repair anything yet. -- 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
Re: Music-files suddenly not recognized anymore, empty files - Btrfschk reports errors
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 able to repair anything yet. Oh, sad to hear that. Ok I guess that means backing up my data and re-formating is probably the best I can do. Thanks, Clemens -- 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
Re: Music-files suddenly not recognized anymore, empty files - Btrfschk reports errors
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 42498768896 bytes used err is 1 total csum bytes: 41015664 total tree bytes: 498728960 total fs tree bytes: 406466560 btree space waste bytes: 110792472 file data blocks allocated: 271306133504 referenced 46886879232 Btrfs Btrfs v0.19 These errors are non-fatal, which kernel are you running? Do you have any btrfs related kernel messages? Did the system crash at all? -chris -- 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
Re: reflinked file size incorrect
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 2.6.35-rc2 and 2.6.35-rc1 -- specifically, Ubuntu 2.6.35-2.3~lucid1-server and 2.6.35-1.1~lucid1-server. Any ideas? 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. sage -- 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
[PATCH] Btrfs: fix CLONE ioctl destination file size expansion to block boundary
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 the originally requested ending offset. This bug was introduced by a22285a6 (2.6.35-rc1). Signed-off-by: Sage Weil s...@newdream.net --- fs/btrfs/ioctl.c | 16 +--- 1 files changed, 13 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 4cdb98c..a687f28 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -1578,6 +1578,7 @@ static noinline long btrfs_ioctl_clone(struct file *file, unsigned long srcfd, u64 disko = 0, diskl = 0; u64 datao = 0, datal = 0; u8 comp; + u64 endoff; size = btrfs_item_size_nr(leaf, slot); read_extent_buffer(leaf, buf, @@ -1712,9 +1713,18 @@ static noinline long btrfs_ioctl_clone(struct file *file, unsigned long srcfd, btrfs_release_path(root, path); inode-i_mtime = inode-i_ctime = CURRENT_TIME; - if (new_key.offset + datal inode-i_size) - btrfs_i_size_write(inode, - new_key.offset + datal); + + /* +* we round up to the block size at eof when +* determining which extents to clone above, +* but shouldn't round up the file size +*/ + endoff = new_key.offset + datal; + if (endoff off+olen) + endoff = off+olen; + if (endoff inode-i_size) + btrfs_i_size_write(inode, endoff); + BTRFS_I(inode)-flags = BTRFS_I(src)-flags; ret = btrfs_update_inode(trans, root, inode); BUG_ON(ret); -- 1.7.0 -- 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
Re: default subvolume abilities/restrictions
On Sat, Jun 12, 2010 at 12:24 AM, C Anthony Risinger anth...@extof.me wrote: On Wed, May 19, 2010 at 9:01 AM, C Anthony Risinger anth...@extof.me wrote: .. i need a way, programmatically and safely, to move the users installation from the original subvolume into an isolated subvolume .. or to generate a new, empty default/root subvolume and place the current default subvol (.) _into_ it... how can this be done? can any devs out there make this happen? note, what i'm looking for is _not_ setting the default subvolume to be mounted, but actually moving/renaming the default (.) subvolume itself. essentially, can we get a command to do this: # btrfs subvolume create new_root # mv . new_root/old_root that unsurprisingly fails with: mv: cannot move `.' to `new_root/old_root': Device or resource busy could we extend btrfs-progs tools to allow something like this? does the on disk format support _moving_ the default subvol? this operation is critical to upgrade a user who has installed their system into the default subvol, as most naturally would. clean rollback systems/structures depend on the user having his system installed to an isolated subvol, NOT the default. what sayith you? i might even try to implement this myself... can i at least get confirmation that the above is possible? all i want to do is create a new/empty subvol, put the old top-level subvol inside it, and make the empty subvol the new root. this lets me put a users installation INTO a subvol even though they originally installed the system into the root subvol. guidance please? chris? :-) thanks, C Anthony -- 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
Re: default subvolume abilities/restrictions
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 # rm -rf old_root Make sure the 'mv' fails fo move new_root, and I'd look at the new_root before removing everything. David -- 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
Re: default subvolume abilities/restrictions
On Sat, Jun 12, 2010 at 7:22 PM, David Brown bt...@davidb.org 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 subvolume snapshot . new_root # mkdir old_root # mv * old_root # rm -rf old_root Make sure the 'mv' fails fo move new_root, and I'd look at the new_root before removing everything. David heh, yeah i as i was writing the last email i realized that all i really wanted was to: # mv * new_root for some reason i was convinced that i must snapshot the old_root (.) to new_root... and then remove the erroneous stuff from old_root (.). thus a way to parent the default subvol (old_root/.) seemed a better solution... but alas, a snapshot isn't necessary. i can create an empty subvol new_root, and then mv * new_root. i don't know how that escaped me :-), sorry for all the noise. however, there probably is a legitimate use case for wanting to replace the default subvolume, but this isn't it. C Anthony -- 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
Re: dkms build error
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 use in this function)
The problem is the blkdev flag name change that occurred in this commit from
Linus' tree around 2.6.35:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fbd9b09a177a481eda256447c881f014f29034fe
which is not in btrfs-unstable. That patch doesn't apply cleanly to the
btrfs-unstable tree so attached is one that just modifies extent-tree.c.
Jim
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index b34d32f..c6a4f45 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -1589,7 +1589,7 @@ static void btrfs_issue_discard(struct block_device *bdev,
u64 start, u64 len)
{
blkdev_issue_discard(bdev, start 9, len 9, GFP_KERNEL,
-DISCARD_FL_BARRIER);
+ BLKDEV_IFL_WAIT | BLKDEV_IFL_BARRIER);
}
static int btrfs_discard_extent(struct btrfs_root *root, u64 bytenr,
Re: reflinked file size incorrect
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 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
