Quoting Stefan Behrens (2013-10-23 13:21:34)
On Tue, 22 Oct 2013 18:55:59 +0200, Bob Marley wrote:
On 22/10/2013 10:37, Stefan Behrens wrote:
I don't believe that this issue can ever happen. I don't believe that
somewhere on the path to the flash memory, to the magnetic disc or to
the
On Thu, Oct 24, 2013 at 12:44:43AM +0800, Eryu Guan wrote:
+_cleanup()
+{
+ cd /
Using root as temporary directory?
+ rm -f $tmp.*
+ $UMOUNT_PROG $loop_mnt
+ _destroy_loop_device $loop_dev1
+ losetup -d $loop_dev2 /dev/null 21
+ _destroy_loop_device $loop_dev3
+
On thu, 24 Oct 2013 06:08:42 -0400, Chris Mason wrote:
Quoting Stefan Behrens (2013-10-23 13:21:34)
On Tue, 22 Oct 2013 18:55:59 +0200, Bob Marley wrote:
On 22/10/2013 10:37, Stefan Behrens wrote:
I don't believe that this issue can ever happen. I don't believe that
somewhere on the path to
On 07/20/2013 12:51 AM, Mark Fasheh wrote:
On Thu, Jul 11, 2013 at 12:26:50AM +0200, David Sterba wrote:
On Wed, Jul 10, 2013 at 10:45:45AM -0700, Mark Fasheh wrote:
Well, what do I get when I pretend I don't care any more? The little voice
in my head says keep plugging away. Here's another
On 10/24/2013 06:08 PM, Chris Mason wrote:
Quoting Stefan Behrens (2013-10-23 13:21:34)
On Tue, 22 Oct 2013 18:55:59 +0200, Bob Marley wrote:
On 22/10/2013 10:37, Stefan Behrens wrote:
I don't believe that this issue can ever happen. I don't believe that
somewhere on the path to the flash
Hi Chris,
this needs to go to 3.12, the patch is only in btrfs-next. The bug can
happen with systemd journal + balance, the fix helps quite a lot of
users out there. (https://bugzilla.kernel.org/show_bug.cgi?id=63411)
I have cherry-picked the patch to current master, applies cleanly and
the test
when i create raid5 in btrfs ,command like this:
./mkfs.btrfs -d raid5 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
/dev/sdg /dev/sdh /dev/sdi /dev/sdj /dev/sdk /dev/sdl /dev/sdm -f
WARNING! - Btrfs v0.20-rc1-358-g194aa4a-dirty IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before
On Thu, Oct 24, 2013 at 10:22:28PM +0800, lilofile wrote:
Oct 24 21:25:36 host1 kernel: [ 3000.809563] [81315c14]
blkdev_issue_discard+0x1b4/0x1c0
There's an discard/TRIM operation being done on all of the devices,
current progs do not report that and it's really confusing. Fixed in
with design revamp around filesystem show the fsid filter
by label wasn't planned. but apparently that seemed to be
necessary. this patch will fix it.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-filesystem.c | 120 -
1 files
Hello Jan,
btrfs_dec_ref() queued a delayed ref for owner of a tree block. The qgroup
tracking is based on delayed refs. The owner of a tree block is set when a
tree block is allocated, it is never updated.
When you allocate a tree block and then remove the subvolume that did the
On Wed, Oct 23, 2013 at 10:08:16AM +0800, Anand Jain wrote:
On 10/22/13 10:33 PM, David Sterba wrote:
On Tue, Oct 22, 2013 at 01:53:22PM +0800, Anand Jain wrote:
@@ -386,7 +395,7 @@ static int btrfs_scan_kernel(void *search)
static const char * const cmd_show_usage[] = {
- btrfs
On Thu, Oct 24, 2013 at 04:51:00PM +0200, David Sterba wrote:
On Wed, Oct 23, 2013 at 10:08:16AM +0800, Anand Jain wrote:
On 10/22/13 10:33 PM, David Sterba wrote:
On Tue, Oct 22, 2013 at 01:53:22PM +0800, Anand Jain wrote:
@@ -386,7 +395,7 @@ static int btrfs_scan_kernel(void *search)
root 734 Oct 24 16:41 @20131024
drwxr-xr-x. 1 root root 734 Oct 24 16:41 F19
drwxr-xr-x. 1 root root 0 Oct 24 17:21 readonly
mv \@20131024 readonly
mv: cannot move ‘@20131024’ to ‘readonly/@20131024’: Read-only file system
I know I can create other new ro snapshots within the readonly
On Thu, October 24, 2013 at 16:49 (+0200), Wang Shilong wrote:
Hello Jan,
btrfs_dec_ref() queued a delayed ref for owner of a tree block. The qgroup
tracking is based on delayed refs. The owner of a tree block is set when a
tree block is allocated, it is never updated.
When you allocate a
arrgh, forgot to mention:
pc2:~ btrfs --version
Btrfs v0.20-rc1
Fedora 19 x86_64
Karl
--
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
The result of the scrubbing came back today and it was not pretty:
...
scrub done for b64daec7-6c14-4996-94b3-80c6abfa26ce
scrub started at Wed Oct 23 23:01:22 2013 and finished after
34990 seconds
total bytes scrubbed: 12.55TB with 3859542 errors
error details:
24 16:31 @20131021
drwxr-xr-x. 1 root root 734 Oct 24 16:36 @20131023
drwxr-xr-x. 1 root root 734 Oct 24 16:41 @20131024
drwxr-xr-x. 1 root root 734 Oct 24 16:41 F19
drwxr-xr-x. 1 root root 0 Oct 24 17:21 readonly
mv \@20131024 readonly
mv: cannot move ‘@20131024’ to ‘readonly
Hello, i suggest temporary solution to use swap file under btrfs.
I test it, and it work good.
I invent simple the way, how create and using swap file, just see
following sh code:
swapfile=$(losetup -f) #free loop device
truncate -s 8G /swap #create 8G sparse swap file
losetup $swapfile /swap
.
..
drwxr-xr-x. 1 root root 734 Oct 24 16:36 @20131023
drwxr-xr-x. 1 root root 734 Oct 24 16:41 @20131024
drwxr-xr-x. 1 root root 734 Oct 24 16:41 F19
drwxr-xr-x. 1 root root 0 Oct 24 17:21 readonly
mv \@20131024 readonly
mv: cannot move ‘@20131024’ to ‘readonly
Hi
(pls see also my other reply in this thread)
On Thu 131024, Duncan wrote:
Karl Kiniger posted on Thu, 24 Oct 2013 17:29:56 +0200 as excerpted:
Dear list, (newbie alert)
After sucessfully sending and receiving a dozen of related snapshots I
want to move them all to the readonly
@20131024 (this is a r/o snap)
It looks to me similar to a read-only mounted filesystem:
pc2:/u2/F19/@20131024# touch foo
touch: cannot touch ‘foo’: Read-only file system
In what way would a r/o snapshot be modified because of moving its
mount point ? No one is ever doing something inside.
Karl
modify it.
tries this all as root.
drwxr-xr-x. 1 root root 734 Oct 24 16:41 @20131024 (this is a r/o snap)
It looks to me similar to a read-only mounted filesystem:
pc2:/u2/F19/@20131024# touch foo
touch: cannot touch ‘foo’: Read-only file system
In what way would a r/o snapshot
Hello Jan,
On 10/24/2013 11:36 PM, Jan Schmidt wrote:
On Thu, October 24, 2013 at 16:49 (+0200), Wang Shilong wrote:
Hello Jan,
btrfs_dec_ref() queued a delayed ref for owner of a tree block. The qgroup
tracking is based on delayed refs. The owner of a tree block is set when a
tree block is
23 matches
Mail list logo
