subject:"\[no subject\]"

Re: [[Missing subject]]

2018-11-23 Thread Qu Wenruo



On 2018/11/23 下午2:41, Andy Leadbetter wrote:
> I have a failing 2TB disk that is part of a 4 disk RAID 6 system.  I
> have added a new 2TB disk to the computer, and started a BTRFS replace
> for the old and new disk.  The process starts correctly however some
> hours into the job, there is an error and kernel oops. relevant log
> below.
> 
> The disks are configured on top of bcache, in 5 arrays with a small
> 128GB SSD cache shared.  The system in this configuration has worked
> perfectly for 3 years, until 2 weeks ago csum errors started
> appearing.  I have a crashplan backup of all files on the disk, so I
> am not concerned about data loss, but I would like to avoid rebuild
> the system.
> 
> btrfs dev stats shows
> [/dev/bcache0].write_io_errs0
> [/dev/bcache0].read_io_errs 0
> [/dev/bcache0].flush_io_errs0
> [/dev/bcache0].corruption_errs  0
> [/dev/bcache0].generation_errs  0
> [/dev/bcache1].write_io_errs0
> [/dev/bcache1].read_io_errs 20
> [/dev/bcache1].flush_io_errs0
> [/dev/bcache1].corruption_errs  0
> [/dev/bcache1].generation_errs  14

Unfortunately, this is not a sign of degrading disk, but something
really went wrong, screwing up some metadata.

For such case, it's recommended to do a "btrfs check --readonly", to
show how serious the problem is.

It could be some subvolume corruption, or some non-essential tree, but
anyway the generation mismatch is a problem that neither kernel or
btrfs-progs has a real good solution.

So at least please consider rebuild the fs.

Despite that, it's recommended to provide the versions of all the
kernels run on the fs, along with the mount option used.

We had some similar reports on such generation mismatch, but still we
don't have a convincing cause for it.
From old kernel to space cache corruption to powerloss + space cache
corruption.

> [/dev/bcache3].write_io_errs0
> [/dev/bcache3].read_io_errs 0
> [/dev/bcache3].flush_io_errs0
> [/dev/bcache3].corruption_errs  0
> [/dev/bcache3].generation_errs  19
> [/dev/bcache2].write_io_errs0
> [/dev/bcache2].read_io_errs 0
> [/dev/bcache2].flush_io_errs0
> [/dev/bcache2].corruption_errs  0
> [/dev/bcache2].generation_errs  2
> 
> and a smart test of the backing disk /dev/bcache1 shows a high read
> error rate, and lot of reallocated sectors.  The disk is 10 years old,
> and has clearly started to fail.
> 
> I've tried the latest kernel, and the latest tools, but nothing will
> allow me to replace, or delete the failed disk.
> 
>   884.171025] BTRFS info (device bcache0): dev_replace from
> /dev/bcache1 (devid 2) to /dev/bcache4 started
> [ 3301.101958] BTRFS error (device bcache0): parent transid verify
> failed on 8251260944384 wanted 640926 found 640907
> [ 3301.241214] BTRFS error (device bcache0): parent transid verify
> failed on 8251260944384 wanted 640926 found 640907
> [ 3301.241398] BTRFS error (device bcache0): parent transid verify
> failed on 8251260944384 wanted 640926 found 640907
> [ 3301.241513] BTRFS error (device bcache0): parent transid verify
> failed on 8251260944384 wanted 640926 found 640907

If btrfs check --readonly only reports this problem, it may be possible
for us to fix it.

Please also do a tree block dump on this block by:
# btrfs ins dump-tree -b 8251260944384 /dev/bcache0

If btrfs check --readonly reports a lot of problems, then it's strongly
recommended to rebuild the filesystem.

Thanks,
Qu

> [ 3302.381094] BTRFS error (device bcache0):
> btrfs_scrub_dev(/dev/bcache1, 2, /dev/bcache4) failed -5
> [ 3302.394612] WARNING: CPU: 0 PID: 5936 at
> /build/linux-5s7Xkn/linux-4.15.0/fs/btrfs/dev-replace.c:413
> btrfs_dev_replace_start+0x281/0x320 [btrfs]
> [ 3302.394613] Modules linked in: btrfs zstd_compress xor raid6_pq
> bcache intel_rapl x86_pkg_temp_thermal intel_powerclamp
> snd_hda_codec_hdmi coretemp kvm_intel snd_hda_codec_realtek kvm
> snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core
> irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hwdep
> snd_pcm pcbc snd_seq_midi aesni_intel snd_seq_midi_event joydev
> input_leds aes_x86_64 snd_rawmidi crypto_simd glue_helper snd_seq
> eeepc_wmi cryptd asus_wmi snd_seq_device snd_timer wmi_bmof
> sparse_keymap snd intel_cstate intel_rapl_perf soundcore mei_me mei
> shpchp mac_hid sch_fq_codel acpi_pad parport_pc ppdev lp parport
> ip_tables x_tables autofs4 overlay nls_iso8859_1 dm_mirror
> dm_region_hash dm_log hid_generic usbhid hid uas usb_storage i915
> i2c_algo_bit drm_kms_helper syscopyarea sysfillrect
> [ 3302.394640]  sysimgblt fb_sys_fops r8169 mxm_wmi mii drm ahci
> libahci wmi video
> [ 3302.394646] CPU: 0 PID: 5936 Comm: btrfs Not tainted
> 4.15.0-20-generic #21-Ubuntu
> [ 3302.394646] Hardware name: System manufacturer System Product
> Name/H110M-R, BIOS 3404 10/10/2017
> [ 3302.394658] RIP: 0010:btrfs_dev_replace_start+0x281/0x320 [btrfs]
> [ 3302.394659] RSP: 0018:a8b582b5fd18 EFLAGS: 00010282
> [ 3302.394660] RAX: fffb RBX:

[no subject]

2018-11-22 Thread Andy Leadbetter

I have a failing 2TB disk that is part of a 4 disk RAID 6 system.  I
have added a new 2TB disk to the computer, and started a BTRFS replace
for the old and new disk.  The process starts correctly however some
hours into the job, there is an error and kernel oops. relevant log
below.

The disks are configured on top of bcache, in 5 arrays with a small
128GB SSD cache shared.  The system in this configuration has worked
perfectly for 3 years, until 2 weeks ago csum errors started
appearing.  I have a crashplan backup of all files on the disk, so I
am not concerned about data loss, but I would like to avoid rebuild
the system.

btrfs dev stats shows
[/dev/bcache0].write_io_errs0
[/dev/bcache0].read_io_errs 0
[/dev/bcache0].flush_io_errs0
[/dev/bcache0].corruption_errs  0
[/dev/bcache0].generation_errs  0
[/dev/bcache1].write_io_errs0
[/dev/bcache1].read_io_errs 20
[/dev/bcache1].flush_io_errs0
[/dev/bcache1].corruption_errs  0
[/dev/bcache1].generation_errs  14
[/dev/bcache3].write_io_errs0
[/dev/bcache3].read_io_errs 0
[/dev/bcache3].flush_io_errs0
[/dev/bcache3].corruption_errs  0
[/dev/bcache3].generation_errs  19
[/dev/bcache2].write_io_errs0
[/dev/bcache2].read_io_errs 0
[/dev/bcache2].flush_io_errs0
[/dev/bcache2].corruption_errs  0
[/dev/bcache2].generation_errs  2

and a smart test of the backing disk /dev/bcache1 shows a high read
error rate, and lot of reallocated sectors.  The disk is 10 years old,
and has clearly started to fail.

I've tried the latest kernel, and the latest tools, but nothing will
allow me to replace, or delete the failed disk.

  884.171025] BTRFS info (device bcache0): dev_replace from
/dev/bcache1 (devid 2) to /dev/bcache4 started
[ 3301.101958] BTRFS error (device bcache0): parent transid verify
failed on 8251260944384 wanted 640926 found 640907
[ 3301.241214] BTRFS error (device bcache0): parent transid verify
failed on 8251260944384 wanted 640926 found 640907
[ 3301.241398] BTRFS error (device bcache0): parent transid verify
failed on 8251260944384 wanted 640926 found 640907
[ 3301.241513] BTRFS error (device bcache0): parent transid verify
failed on 8251260944384 wanted 640926 found 640907
[ 3302.381094] BTRFS error (device bcache0):
btrfs_scrub_dev(/dev/bcache1, 2, /dev/bcache4) failed -5
[ 3302.394612] WARNING: CPU: 0 PID: 5936 at
/build/linux-5s7Xkn/linux-4.15.0/fs/btrfs/dev-replace.c:413
btrfs_dev_replace_start+0x281/0x320 [btrfs]
[ 3302.394613] Modules linked in: btrfs zstd_compress xor raid6_pq
bcache intel_rapl x86_pkg_temp_thermal intel_powerclamp
snd_hda_codec_hdmi coretemp kvm_intel snd_hda_codec_realtek kvm
snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core
irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hwdep
snd_pcm pcbc snd_seq_midi aesni_intel snd_seq_midi_event joydev
input_leds aes_x86_64 snd_rawmidi crypto_simd glue_helper snd_seq
eeepc_wmi cryptd asus_wmi snd_seq_device snd_timer wmi_bmof
sparse_keymap snd intel_cstate intel_rapl_perf soundcore mei_me mei
shpchp mac_hid sch_fq_codel acpi_pad parport_pc ppdev lp parport
ip_tables x_tables autofs4 overlay nls_iso8859_1 dm_mirror
dm_region_hash dm_log hid_generic usbhid hid uas usb_storage i915
i2c_algo_bit drm_kms_helper syscopyarea sysfillrect
[ 3302.394640]  sysimgblt fb_sys_fops r8169 mxm_wmi mii drm ahci
libahci wmi video
[ 3302.394646] CPU: 0 PID: 5936 Comm: btrfs Not tainted
4.15.0-20-generic #21-Ubuntu
[ 3302.394646] Hardware name: System manufacturer System Product
Name/H110M-R, BIOS 3404 10/10/2017
[ 3302.394658] RIP: 0010:btrfs_dev_replace_start+0x281/0x320 [btrfs]
[ 3302.394659] RSP: 0018:a8b582b5fd18 EFLAGS: 00010282
[ 3302.394660] RAX: fffb RBX: 927d3afe RCX: 
[ 3302.394660] RDX: 0001 RSI: 0296 RDI: 927d3afece90
[ 3302.394661] RBP: a8b582b5fd68 R08:  R09: a8b582b5fc18
[ 3302.394662] R10: a8b582b5fd10 R11:  R12: 927d3afece20
[ 3302.394662] R13: 927d34b59421 R14: 927d34b59020 R15: 0001
[ 3302.394663] FS:  7fba4831c8c0() GS:927df6c0()
knlGS:
[ 3302.394664] CS:  0010 DS:  ES:  CR0: 80050033
[ 3302.394664] CR2: 2b9b83db85b8 CR3: 000164d3a002 CR4: 003606f0
[ 3302.394665] Call Trace:
[ 3302.394676]  btrfs_dev_replace_by_ioctl+0x39/0x60 [btrfs]
[ 3302.394686]  btrfs_ioctl+0x1988/0x2080 [btrfs]
[ 3302.394689]  ? iput+0x8d/0x220
[ 3302.394690]  ? __blkdev_put+0x199/0x1f0
[ 3302.394692]  do_vfs_ioctl+0xa8/0x630
[ 3302.394701]  ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]
[ 3302.394703]  ? do_vfs_ioctl+0xa8/0x630
[ 3302.394704]  ? do_sigaction+0xb4/0x1e0
[ 3302.394706]  SyS_ioctl+0x79/0x90
[ 3302.394708]  do_syscall_64+0x73/0x130
[ 3302.394710]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 3302.394711] RIP: 0033:0x7fba471085d7
[ 3302.394712] RSP: 002b:7ffe5af753b8 EFLAGS: 0246 ORIG_RAX:
0010
[

[no subject]

2018-07-28 Thread Andrew Martinez




Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere 
Informationen

Do you need a loan of any kind? If Yes email us now for more info

[no subject]

2018-07-28 Thread Andrew Martinez




Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere 
Informationen

Do you need a loan of any kind? If Yes email us now for more info

[no subject]

2018-07-28 Thread Andrew Martinez




Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere 
Informationen

Do you need a loan of any kind? If Yes email us now for more info

[no subject]

2018-07-23 Thread Stefan Etzkorn

 subscribe linux-btrfs

[no subject]

2018-04-17 Thread Timo Nentwig


unsubscribe linux-kernel
--
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

[no subject]

2018-03-22 Thread Mason Fan

Hi all,
I read from a SNIA's slide that btrfs will support host managed SMR device 
natively, and also saw it in "Features Currently in Development or Planned for 
Future Implementation" on the wiki. Does anyone know any further information? 
Like the schedule? Thanks.
--
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

[no subject]

2018-02-18 Thread Tomasz Kłoczko

Hi,

For some reasons btrfs pool each volume is not displayed in mount and
df output, and I cannot find how to display volumes/snapshots usage
using btrfs command.
I'm looking for equivalent of the "zfs list -r -t [all|snapshot,filesystem]"
https://docs.oracle.com/cd/E23824_01/html/821-1448/gazsu.html#scrolltoc
Can someone help with exact command syntax?
As it is a quite basic function I think that some man page must be not
up-to-date or I'm looking at the wrong doc .. or I'm just blind :-/

Another question related to btrfs functionalities.
Is anyone working on the analog of zfs delegations?
https://docs.oracle.com/cd/E23824_01/html/821-1448/gbchv.html#scrolltoc

I'm using now btrfs quite intensively and I'm trying to use btrfs as
same way as I've been using for veeery long time zfs :-P
So now I have many volumes and snapshots in my home directory, but to
maintain all this I must use root permission. As non-root working in
my own home which is separated btrfs volume it would be nice to have
the possibility to delegate permission to create, destroy,
send/receive, mount/umount etc. snapshots, volumes like it os possible
on zfs.

BTW: someone maybe started working on something like .zfs hidden
directory functions which is in each zfs volume mountpoint?
Have few or few tenths snapshots is not so big deal but the same on
scale few hundreds, thousands or more snapshots I think that would be
really hard without something like hidden .btrfs/snapshots directory.
On zfs .zfs/snapshots directory is especially useful when the volume
is exported over for example NFS. With zfs volume exported over NFS on
NFS client is possible to do "mkdir .zfs/snapshot/my_snapshot" to
create the snapshot (even from NFS client working on Windows) or
"rmdir .zfs/snapshot/my_snapshot" to destroy snapshot from remote NFS
client system. All without login over for example ssh on NFS server.

And last question.
As Linux has now containers which provide most of the core Solaris
non-global zones functions it would be good to have as well equivalent
of the zfs zoned property.
https://docs.oracle.com/cd/E19253-01/819-5461/gbbre/index.html
Someone maybe started working on something like this for btrfs?

After few years not using btrfs (because previously was quite
unstable) It is really good to see that now I'm not able to crash it.
I must say "big thank you" to all those people involved in reaching
current state :)

kloczek

-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
--
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

[no subject]

2017-11-13 Thread Friedrich Mayrhofer



This is the second time i am sending you this Email.

I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me  
personally for more details.


Regards.
Friedrich Mayrhofer






This message was sent using IMP, the Internet Messaging Program.

--
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: Fixed subject: updatedb does not index separately mounted btrfs subvolumes

2017-11-05 Thread Peter Grandi

>> The issue is that updatedb by default will not index bind
>> mounts, but by default on Fedora and probably other distros,
>> put /home on a subvolume and then mount that subvolume which
>> is in effect a bind mount.

> 

> So the issue isn't /home being btrfs (as you said in the
> subject), but rather, it's /home being an explicitly mounted
> subvolume, since btrfs uses bind-mounts internally for
> subvolume mounts.

That to me seems like rather improper terminology and notes, and
I would consider these to be more appropriate:

* There are entities known as "root directories", and their main
  property is that all inodes reachable from one in the same
  filesystem have the same "device id".
* Each "filesystem" has at least one, and a Btrfs "volume" has
  one for every "subvolume", including the "top subvolume".
* A "root directory" can be "mounted" on a "mount point"
  directory of another "filesystem", which allows navigating
  from one filesystem to another.
* A "mounted" root directory can be identified by the device id
  of '.' being different from that of '..'.
* In Linux a "root directory" can be "mounted" onto several
  "mount point" directories at the same time.
* In Linux a "bind" operation is not a "mount" operation, it is
  in effect a kind of temporary "hard link", one that makes a
  directory aliased to a "bind point" directory.

Looking at this:

  tree#  tail -3 /proc/mounts   

 
  /dev/mapper/sda7 /fs/sda7 btrfs 
rw,nodiratime,relatime,nossd,nospace_cache,user_subvol_rm_allowed,subvolid=5,subvol=/
 0 0
  /dev/mapper/sda7 /fs/sda7/bind btrfs 
rw,nodiratime,relatime,nossd,nospace_cache,user_subvol_rm_allowed,subvolid=431,subvol=/=
 0 0
  /dev/mapper/sda7 /fs/sda7/bind-tmp btrfs 
rw,nodiratime,relatime,nossd,nospace_cache,user_subvol_rm_allowed,subvolid=431,subvol=/=/tmp
 0 0

  tree#  stat --format "%3D %6i %N" {,/fs,/fs/sda7}/{.,..} 
/fs/sda7/{=,=/subvol,=/subvol/dir,=/tmp,bind,bind-tmp}/{.,..} 
  806  2 ‘/.’
  806  2 ‘/..’
   23  36176 ‘/fs/.’
  806  2 ‘/fs/..’
   26256 ‘/fs/sda7/.’
   23  36176 ‘/fs/sda7/..’
   27256 ‘/fs/sda7/=/.’
   26256 ‘/fs/sda7/=/..’
   2b256 ‘/fs/sda7/=/subvol/.’
   27256 ‘/fs/sda7/=/subvol/..’
   2b258 ‘/fs/sda7/=/subvol/dir/.’
   2b256 ‘/fs/sda7/=/subvol/dir/..’
   27 344618 ‘/fs/sda7/=/tmp/.’
   27256 ‘/fs/sda7/=/tmp/..’
   27256 ‘/fs/sda7/bind/.’
   26256 ‘/fs/sda7/bind/..’
   27 344618 ‘/fs/sda7/bind-tmp/.’
   26256 ‘/fs/sda7/bind-tmp/..’

It shows that subvolume root directories are "mount points" and
not "bind points" (note that ‘/fs/sda7/=/subvol’ is not
explicitly mounted, yet its '.' and '..' have different device
ids), and that "bind points" appear as if they were ordinary
directories (an unwise decision I suspect).

Many tools for UNIX-like systems don't cross "mount point"
directories (or follow symbolic links), by default or with an
option, but will cross "bind point" directories as they look
like ordinary directories.

For 'mlocate' the "bind point" directories are a special case,
handled by looking up every directory examined in the list of
"bind point" directories, as per line 381 here:

https://pagure.io/mlocate/blob/master/f/src/bind-mount.c#_381
--
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: Fixed subject: updatedb does not index separately mounted btrfs subvolumes

2017-11-05 Thread Chris Murphy

On Sun, Nov 5, 2017 at 1:47 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Chris Murphy posted on Fri, 03 Nov 2017 18:15:53 -0600 as excerpted:
>
>> Ancient bug, still seems to be a bug.
>> https://bugzilla.redhat.com/show_bug.cgi?id=906591
>>
>> The issue is that updatedb by default will not index bind mounts, but by
>> default on Fedora and probably other distros, put /home on a subvolume
>> and then mount that subvolume which is in effect a bind mount.
>
> 
>
> So the issue isn't /home being btrfs (as you said in the subject), but
> rather, it's /home being an explicitly mounted subvolume, since btrfs
> uses bind-mounts internally for subvolume mounts.
>
> Makes a difference for folks like me who have /home on a fully separate
> btrfs.  You had me wondering for a moment, tho as it happens I don't use
> updatedb either, but I was still wondering what weird bug and how it
> might otherwise affect me.  An accurate subject line would have helped...


It is accurate, it's an exactly copied title from the bug report. That
the bug report's title is confusing is sorta beside the point, I
certainly can't do anything about that.

-- 
Chris Murphy
--
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

Fixed subject: updatedb does not index separately mounted btrfs subvolumes

2017-11-05 Thread Duncan

Chris Murphy posted on Fri, 03 Nov 2017 18:15:53 -0600 as excerpted:

> Ancient bug, still seems to be a bug.
> https://bugzilla.redhat.com/show_bug.cgi?id=906591
> 
> The issue is that updatedb by default will not index bind mounts, but by
> default on Fedora and probably other distros, put /home on a subvolume
> and then mount that subvolume which is in effect a bind mount.



So the issue isn't /home being btrfs (as you said in the subject), but 
rather, it's /home being an explicitly mounted subvolume, since btrfs 
uses bind-mounts internally for subvolume mounts.

Makes a difference for folks like me who have /home on a fully separate 
btrfs.  You had me wondering for a moment, tho as it happens I don't use 
updatedb either, but I was still wondering what weird bug and how it 
might otherwise affect me.  An accurate subject line would have helped...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
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

[no subject]

2017-10-19 Thread Denis 'GNUtoo' Carikli

subscribe linux-btrfs
--
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

[no subject]

2017-08-02 Thread Thomas Wurfbaum

subscribe linux-btrfs

--
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

[no subject]

2017-07-27 Thread Su Yue


subscribe linux-btrfs


--
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

[no subject]

2017-05-28 Thread Ilan Schwarts

unsubscribe linux-btrfs


-- 


-
Ilan Schwarts
--
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

[no subject]

2017-05-08 Thread Gu, Jinxiang

subscribe linux-btrfs

[no subject]

2017-05-08 Thread Gu, Jinxiang

subscribe linux-btrfs

Subject: [PATCH 2/3 v2] Prevent attempt to insert extent record with max_size==0

2017-04-28 Thread Christophe de Dinechin

When this happens, we will trip a BUG_ON(end < start) in insert_state
because in check_extent_refs, we use this max_size expecting it's not zero:

  set_extent_dirty(root->fs_info->excluded_extents,
   rec->start,
   rec->start + rec->max_size - 1);

See https://bugzilla.redhat.com/show_bug.cgi?id=1435567
for an example where this scenario occurs.

Signed-off-by: Christophe de Dinechin 
---
 cmds-check.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cmds-check.c b/cmds-check.c
index 2d3ebc1..c13f900 100644
--- a/cmds-check.c
+++ b/cmds-check.c
@@ -6029,6 +6029,7 @@ static int add_extent_rec_nolookup(struct cache_tree 
*extent_cache,
struct extent_record *rec;
int ret = 0;
 
+   BUG_ON(tmpl->max_size == 0);
rec = malloc(sizeof(*rec));
if (!rec)
return -ENOMEM;
-- 
2.9.3

--
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

[no subject]

2017-03-19 Thread Ilan Schwarts

Hi,
sorry if this is a newbie question. I am newbie.

In my kernel driver, I get device id by converting struct inode struct
to btrfs_inode, I use the code:
struct btrfs_inode *btrfsInode;
btrfsInode = BTRFS_I(inode);

I usually download kernel-headers rpm package, this is not enough. it
fails to find the btrfs header files.

I had to download them not via rpm package and declare:
#include "/data/kernel/linux-4.1.21-x86_64/fs/btrfs/ctree.h"
#include "/data/kernel/linux-4.1.21-x86_64/fs/btrfs/btrfs_inode.h"

This is not good, why ctree.h and btrfs_inode.h are not in kernel headers?
Is there another package i need to download in order to get them, in
addition to kernel-headers? ?


I see they are not provided in kernel-header package, e.g:
https://rpmfind.net/linux/RPM/fedora/23/x86_64/k/kernel-headers-4.2.3-300.fc23.x86_64.html

Thanks!
--
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

[no subject]

2017-03-15 Thread Alexandr Unger

Hi to everyone here!

Firstly thank you all for this amasing project!

I want to claim "virtual TAG file system" feature to be implemented in BTRFS.

What is it?

It is a feature to simplify use and search data (files) with common tags.

Some tags may be defined as a file attribute, like year of creation&|change
so user can access same file with different (virtual) paths like:

two diff files under ~/vtagfs/root/ :
firm1/reports/2016/report
firm1/reports/2017/report
(firm1/reports/2017/.tags/report - sysfile with all tags for this file)
... and
2017/reports/firm1/report - will be link to second one

also may be set by default automatic lock to edit files with "old year
tag"... and so on...


How it can works.

/etc/vtagfs/ - place for global configs
~/.vtagfs/ - user space for configs

~/vtagfs/ - default or fixed place for data and links
~/vtagfs/.tags/ - place for data used by vtagfs itself
~/vtagfs/root/ - (root is fixed dir for all data operated by users'
vtagfs - to be known by other programs)
~/vtagfs/root/tag1/ - place for data with tag1 (only tag1)
~/vtagfs/root/tag1/.tag - file marker that this dir is used as a tag.
It maybe used to declare
possible sets of tags with this one.

~/vtagfs/root/tag1//tag2/ - place for data with tag1 & tag2
...
~/vtagfs/tag1/tag2 - slink showed to user
~/vtagfs/tag1/tag3 - slink showed to user
~/vtagfs/tag2/tag1 - slink showed to user
~/vtagfs/tag2/tag3 - slink showed to user
~/vtagfs/tag1/tag2/tag3/ - slink showed to user
...
Sure, must be something like tagManager to define/operate with tags
used by user.

or/and it can be realized as transparent to user/system requests like mkdir, so
mkdir tag1 inside ~/vtagfs/  will create tag1...
and cp file1 tag1/tag2/tag3/ - will set these tags to file1 ...
  ... and make cp file1 ~/vtagfs/root/tag1/tag2/tag3/ where will
be real place of file, known to system.

Hope this feature will be useful, so thank you all for patience :)

Best regards, and welcome to https://l-in-k.com

Alexandr.

http://ungerware.biz
https://l-in-k.com/147a258u369
--
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: Subject: [REVERT][v4.x.y] btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl

2017-02-02 Thread Greg KH

On Thu, Feb 02, 2017 at 12:38:33PM -0500, Joseph Salisbury wrote:
> Hello,
> 
> Please consider reverting commit
> 4c63c2454eff996c5e27991221106eb511f7db38 in the next v4.x.y release.

What release can I remove it from?

It isn't in 4.4.y, and 4.9.y doesn't make much sense, unless it's
reverted in Linus's tree already?

totally confused.

greg k-h
--
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

Subject: [REVERT][v4.x.y] btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl

2017-02-02 Thread Joseph Salisbury

Hello,

Please consider reverting commit
4c63c2454eff996c5e27991221106eb511f7db38 in the next v4.x.y release.  It
was included upstream as of v4.7-rc1  This commit introduced a
regression, described in the following bug:
http://bugs.launchpad.net/bugs/1619918

This new regression was discussed in the following thread:

https://lkml.org/lkml/2017/1/6/467


Sincerely,

Joseph Salisbury


--
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

[no subject]

2016-12-04 Thread Ed Nadolski

subscribe linux-btrfs
--
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

[no subject]

2016-11-28 Thread foss

Hello,

I have a multi-device btrfs (with problems, more on that later). I looked into 
btrfs-image and was surprised to find that "for i in 5 6 7 8 ; do sudo 
btrfs-image -t2 /dev/sda$i - | md5sum;done" returns a different hash for sda7.  
The other three hashes are the same, as I believe they all should be, or am I 
mistaken?

$ for i in 5 6 7 8 ; do echo -n sda$i:" " ; sudo btrfs-image -t2 -c9 /dev/sda$i 
- | tee /tmp/sda$i.img | md5sum;done
sda5: 047a1da23edeb9661e79d1006f17eab0  -
sda6: 047a1da23edeb9661e79d1006f17eab0  -
sda7: 9cc7afdc1476daa6f671db8d3c855164  -
sda8: 047a1da23edeb9661e79d1006f17eab0  -

$ sudo btrfs fi show
Label: 'SSD128'  uuid: f110a925-6ad9-4b40-9207-6bf09ce0cb23
Total devices 4 FS bytes used 105.96GiB
devid1 size 100.00GiB used 100.00GiB path /dev/sda5
devid2 size 10.00GiB used 10.00GiB path /dev/sda6
devid3 size 5.00GiB used 5.00GiB path /dev/sda7
devid4 size 1.99GiB used 1.00GiB path /dev/sda8

The difference is somewhere very early on in the file:
$ wc -c /tmp/sda?.img
223763456 /tmp/sda5.img
223763456 /tmp/sda6.img
223763456 /tmp/sda7.img
223763456 /tmp/sda8.img
895053824 total
$ for file in /tmp/sda?.img;do echo -n $file: " "; tail -c 22295 $file | 
md5sum;done
/tmp/sda5.img:  afe8010fa089415aaa55f2d549c3b5d4  -
/tmp/sda6.img:  afe8010fa089415aaa55f2d549c3b5d4  -
/tmp/sda7.img:  afe8010fa089415aaa55f2d549c3b5d4  -
/tmp/sda8.img:  afe8010fa089415aaa55f2d549c3b5d4  -
$ for file in /tmp/sda?.img;do echo -n $file: " "; tail -c 22296 $file | 
md5sum;done
/tmp/sda5.img:  2bc5fe13e5f2dd8592a24eecb322482e  -
/tmp/sda6.img:  2bc5fe13e5f2dd8592a24eecb322482e  -
/tmp/sda7.img:  ee26d34afa50ccb33e95e869b3e18af3  -
/tmp/sda8.img:  2bc5fe13e5f2dd8592a24eecb322482e  -

How could this be?

Regards

Rolf


PS: While I will check back for replies in the archive, a courtesy cc will be 
appreciated since I am not subscribed to the list.
--
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

[no subject]

2016-11-09 Thread bepi

Hi.

I'm making a script for managing btrfs.

To perform the scrub, to create and send (even to a remote system) of the backup
snapshot (or for one copy of the current state of the data).

The script is designed to:
- Be easy to use:
  - The preparation is carried out automatically.
  - Autodetect of the subvolume mounted.
- Be safe and robust:
  - Check that not exist a another btrfs managing already started.
  - Subvolume for created and received snapshot are mounted and accessible only
for the time necessary to perform the requested operation.
  - Verify that the snapshot and sending snapshot are been executed completely.
  - Progressive numbering of the snapshots for identify with certainty
the latest snapshot.

Are also available command for view the list of snaphost present, command for
delete the snapshots.

For example:

btrsfManage SCRUB /
btrsfManage SNAPSHOT /
btrsfManage SEND / /dev/sda1
btrsfManage SEND / r...@gdb.exnet.it/dev/sda1
btrsfManage SNAPLIST /dev/sda1
btrsfManage SNAPDEL /dev/sda1 "root-2016-11*"

You are interested?

Gdb



This mail has been sent using Alpikom webmail system
http://www.alpikom.it

--
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

[no subject]

2016-08-31 Thread Fennec Fox

Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
2016 x86_64 GNU/Linux
btrfs-progs v4.7

Data, single: total=30.01GiB, used=18.95GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=1.01GiB, used=422.17MiB
GlobalReserve, single: total=144.00MiB, used=0.00B

{02:50} Wed Aug 31
[fennectech@Titanium ~]$  sudo fstrim -v /
[sudo] password for fennectech:
Sorry, try again.
[sudo] password for fennectech:
/: 99.8 GiB (107167244288 bytes) trimmed

{03:08} Wed Aug 31
[fennectech@Titanium ~]$  sudo fstrim -v /
[sudo] password for fennectech:
/: 99.9 GiB (107262181376 bytes) trimmed

  I ran these commands minutes after echother ane each time it is
trimming the entire free space

Anyone else seen this?   the filesystem is the root FS and is compressed

-- 
Fennec
--
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

[no subject]

2016-08-12 Thread Gulf Energy Electro-Mech.Works

Dear Sir/Madam

I have a business proposal for you that will be of mutual benefit to
both of us. It’s about the death of my late client and some money he
left behind before his death. I want you to stand as his next of kin
since you bear the same surname with him, so that the bank can
release/transfer his money to you as his next of kin. Contact me for
more details contact us via our official email address:
alfredmarc1...@hotmail.com

I look forward hearing from you as soon as possible If you are willing
to proceed with me

Barrister Alfred Marc
--
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

[no subject]

2016-08-12 Thread Alfred Marc

Dear Sir/Madam

I have a business proposal for you that will be of mutual benefit to
both of us. It’s about the death of my late client and some money he
left behind before his death. I want you to stand as his next of kin
since you bear the same surname with him, so that the bank can
release/transfer his money to you as his next of kin. Contact me for
more details contact us via our official email address:
alfredmarc1...@hotmail.com

I look forward hearing from you as soon as possible If you are willing
to proceed with me

Barrister Alfred Marc
--
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

[no subject]

2016-03-30 Thread Sanidhya Solanki

subscribe linux-btrfs
--
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

[no subject]

2016-02-07 Thread Andreas Hild

subscribe linux-btrfs
--
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

[no subject]

2015-09-29 Thread Paride Legovini

subscribe linux-btrfs
--
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

[no subject]

2015-09-29 Thread Paride Legovini

subscribe linux-btrfs
--
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

[no subject]

2015-09-17 Thread Калинина Зинаида

Посмотреть цены и ассортимент rusrusrus.ru

 

 

--
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

[no subject]

2015-07-22 Thread 조경민

subscribe linux-btrfs
--
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

[no subject]

2015-06-14 Thread Onkar N Mahajan

subscribe linux-btrfs
--
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

(no subject)

2015-06-03 Thread Irena A.


Hello

My name is Irena .A, I am sending this brief letter to solicit your 
partnership to transfer €22,500,000.00 Euros,if interested kindly write 
back for more information.


irenageorgia...@qq.com

Irena .A.
--
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

[no subject]

2015-03-26 Thread Dunsmore, Alethia





Do you need any financial assistance? if yes,
Contact us with this email:  
richardmalc...@foxmail.commailto:richardmalc...@foxmail.com





 In Spanish



¿Necesita alguna ayuda económica? en caso afirmativo,
Póngase en contacto con nosotros con este correo electrónico: 
richardmalc...@foxmail.commailto:richardmalc...@foxmail.com
--
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

[no subject]

2014-02-02 Thread Steffen Sindzinski



--
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

[no subject]

2013-12-31 Thread Emirates




--
We sent you a mail and no reply. Please does the email exist.
--

--
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

[no subject]

2013-12-17 Thread David Sterba

Subject: [PATCH 4/3] btrfs: check balance of send_in_progress

Warn if the balance goes below zero, which appears to be unlikely
though. Otherwise cleans up the code a bit.

Signed-off-by: David Sterba dste...@suse.cz
---

A followup to 3/3 that adds the check if send_in_progress is not going below
zero. It's a separate patch rather than folded into 3/3 so the change is
clearly visible. I'm not convinced that it's necessary to be that cautious
because it looks almost impossible to happen, but on the other hand we'd never
know that it happened.

 fs/btrfs/send.c |   38 --
 1 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 468eba26ad8c..46ea0cdfb88b 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -4618,6 +4618,21 @@ out:
return ret;
 }
 
+static void btrfs_root_dec_send_in_progress(struct btrfs_root* root)
+{
+   spin_lock(root-root_item_lock);
+   root-send_in_progress--;
+   /*
+* Not much left to do, we don't know why it's unbalanced and
+* can't blindly reset it to 0.
+*/
+   if (root-send_in_progress  0)
+   btrfs_err(root-fs_info,
+   send_in_progres unbalanced %d root %llu\n,
+   root-send_in_progress, root-root_key.objectid);
+   spin_unlock(root-root_item_lock);
+}
+
 long btrfs_ioctl_send(struct file *mnt_file, void __user *arg_)
 {
int ret = 0;
@@ -4835,24 +4850,11 @@ long btrfs_ioctl_send(struct file *mnt_file, void 
__user *arg_)
}
 
 out:
-   for (i = 0; i  clone_sources_to_rollback; i++) {
-   struct btrfs_root *r = sctx-clone_roots[i].root;
-
-   spin_lock(r-root_item_lock);
-   r-send_in_progress--;
-   spin_unlock(r-root_item_lock);
-   }
-   if (!IS_ERR(sctx-parent_root)) {
-   struct btrfs_root *r = sctx-parent_root;
-
-   spin_lock(r-root_item_lock);
-   r-send_in_progress--;
-   spin_unlock(r-root_item_lock);
-   }
-
-   spin_lock(send_root-root_item_lock);
-   send_root-send_in_progress--;
-   spin_unlock(send_root-root_item_lock);
+   for (i = 0; i  clone_sources_to_rollback; i++)
+   btrfs_root_dec_send_in_progress(sctx-clone_roots[i].root);
+   if (!IS_ERR(sctx-parent_root))
+   btrfs_root_dec_send_in_progress(sctx-parent_root);
+   btrfs_root_dec_send_in_progress(send_root);
 
kfree(arg);
vfree(clone_sources_tmp);
-- 
1.7.9

--
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

[no subject]

2013-10-29 Thread Goffredo Baroncelli

help
-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
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

[no subject]

2013-06-17 Thread AFG GTBANK LOAN




Loan Syndicacion

Am AFG Guaranty Trust Bank, zu strukturieren wir Kreditlinien treffen Sie
unsere
Kunden spezifischen geschäftlichen Anforderungen und einen deutlichen
Mehrwert für unsere
Kunden Unternehmen.
eine Division der AFG Finance und Private Bank plc.

Wenn Sie erwägen, eine große Akquisition oder ein Großprojekt sind, können
Sie
brauchen eine erhebliche Menge an Kredit. AFG Guaranty Trust Bank setzen
können
zusammen das Syndikat, das die gesamte Kredit schnürt für
Sie.


Als Bank mit internationaler Reichweite, sind wir gekommen, um Darlehen zu
identifizieren
Syndizierungen als Teil unseres Kerngeschäfts und durch spitzte diese Zeile
aggressiv sind wir an einem Punkt, wo wir kommen, um als erkannt haben
Hauptakteur in diesem Bereich.


öffnen Sie ein Girokonto heute mit einem Minimum Bankguthaben von 500 £ und
Getup zu £ 10.000 als Darlehen und auch den Hauch einer Chance und gewann
die Sterne
Preis von £ 500.000 in die sparen und gewinnen promo in may.aply jetzt.


mit dem Folowing Informationen über Rechtsanwalt steven lee das Konto
Offizier.


FULL NAME;


Wohnadresse;


E-MAIL-ADRESSE;

Telefonnummer;

Nächsten KINS;

MUTTER MAIDEN NAME;


Familienstand;


BÜROADRESSE;

ALTERNATIVE Telefonnummer;

TO @ yahoo.com bar.stevenlee
NOTE; ALLE Darlehen sind für 10JAHRE RATE VALID
ANGEBOT ENDET BALD SO JETZT HURRY

--
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

[no subject]

2013-05-28 Thread Alex Lyakas

Hello all,
I have the following unresponsive btrfs:

btrfs_end_transaction() is called and is stuck in btrfs_tree_lock():

May 27 16:13:55 vc kernel: [ 7130.421159] kworker/u:85D
 0 19859  2 0x
May 27 16:13:55 vc kernel: [ 7130.421159]  880095335568
0046 00010093cb38 880083b11b48
May 27 16:13:55 vc kernel: [ 7130.421159]  880095335fd8
880095335fd8 880095335fd8 00013f40
May 27 16:13:55 vc kernel: [ 7130.421159]  8800a1fddd00
88008b1fc5c0 880095335578 880090f736d8
May 27 16:13:55 vc kernel: [ 7130.421159] Call Trace:
May 27 16:13:55 vc kernel: [ 7130.421159]  [816eb399]
schedule+0x29/0x70
May 27 16:13:55 vc kernel: [ 7130.421159]  [a03665ad]
btrfs_tree_lock+0xcd/0x250 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [8107fcc0] ?
add_wait_queue+0x60/0x60
May 27 16:13:55 vc kernel: [ 7130.421159]  [a031d558]
btrfs_init_new_buffer+0x68/0x140 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a031d70d]
btrfs_alloc_free_block+0xdd/0x460 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [8113ff9b] ?
__set_page_dirty_nobuffers+0x1b/0x20
May 27 16:13:55 vc kernel: [ 7130.421159]  [a0327b2e] ?
btree_set_page_dirty+0xe/0x10 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a0307756]
__btrfs_cow_block+0x126/0x4f0 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a0307cc3]
btrfs_cow_block+0x123/0x1d0 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a030c281]
btrfs_search_slot+0x381/0x820 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a03138ce]
lookup_inline_extent_backref+0x8e/0x5b0 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a032b6e9] ?
btrfs_mark_buffer_dirty+0x99/0xf0 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a031301e] ?
setup_inline_extent_backref+0x18e/0x290 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a0313e53]
insert_inline_extent_backref+0x63/0x130 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a030677a] ?
btrfs_alloc_path+0x1a/0x20 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a031486f]
__btrfs_inc_extent_ref+0x9f/0x240 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a0377aa9] ?
btrfs_merge_delayed_refs+0x289/0x300 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a031b3a1]
run_clustered_refs+0x971/0xd00 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a030714d] ?
btrfs_put_tree_mod_seq+0x10d/0x150 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a031f7f0]
btrfs_run_delayed_refs+0xd0/0x320 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a0330bf7]
__btrfs_end_transaction+0xf7/0x410 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.421159]  [a0330f60]
btrfs_end_transaction+0x10/0x20 [btrfs]

As a result, transaction cannot commit, it waits for all writers to
detach in the do-while loop.

May 27 16:13:55 vc kernel: [ 7130.419009] btrfs-transacti D
 0 15150  2 0x
May 27 16:13:55 vc kernel: [ 7130.419012]  88009f86bce8
0046 032d032d 
May 27 16:13:55 vc kernel: [ 7130.419016]  88009f86bfd8
88009f86bfd8 88009f86bfd8 00013f40
May 27 16:13:55 vc kernel: [ 7130.419020]  8800af1e9740
8800a03f8000 0090 88009693cb00
May 27 16:13:55 vc kernel: [ 7130.419023] Call Trace:
May 27 16:13:55 vc kernel: [ 7130.419027]  [816eb399]
schedule+0x29/0x70
May 27 16:13:55 vc kernel: [ 7130.419031]  [816e9b1d]
schedule_timeout+0x1ed/0x250
May 27 16:13:55 vc kernel: [ 7130.419055]  [a03497a3] ?
btrfs_run_ordered_operations+0x2b3/0x2e0 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.419060]  [81045cd9] ?
default_spin_lock_flags+0x9/0x10
May 27 16:13:55 vc kernel: [ 7130.419081]  [a0330388]
btrfs_commit_transaction+0x3b8/0xae0 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.419085]  [8107fcc0] ?
add_wait_queue+0x60/0x60
May 27 16:13:55 vc kernel: [ 7130.419104]  [a0328525]
transaction_kthread+0x1b5/0x230 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.419124]  [a0328370] ?
btree_invalidatepage+0x80/0x80 [btrfs]
May 27 16:13:55 vc kernel: [ 7130.419128]  [8107f0d0]
kthread+0xc0/0xd0
May 27 16:13:55 vc kernel: [ 7130.419132]  [8107f010] ?
flush_kthread_worker+0xb0/0xb0
May 27 16:13:55 vc kernel: [ 7130.419136]  [816f506c]
ret_from_fork+0x7c/0xb0
May 27 16:13:55 vc kernel: [ 7130.419140]  [8107f010] ?
flush_kthread_worker+0xb0/0xb0

There is additional thread stuck in btrfs_tree_lock(), not sure how it
is related, perhaps there's some deadlock between the two?

May 27 16:13:55 vc kernel: [ 7130.421159] flush-btrfs-2   D
0001 0 18816  2 0x
May 27 16:13:55 vc kernel: [ 7130.421159]  88008b553948
0046 880017991050 
May 27 16:13:55 vc kernel: [ 7130.421159]

[no subject]

2013-04-27 Thread Peter Würtz

Hi!

I recently had some trouble with my root and home btrfs filesystems.
My system (Ubuntu 13.04, Kernel 3.8) started freezing when copying
larger numbers of files around (hard freeze, no logs about what
happened).

At some time booting up wasn't possible anymore due to a kernel bug
while mounting the homefs. Btrfsck built from git wasn't able to
repair the fs and segfaulted. Btrfs-zero-log was able to make home
mountable again and the fs is clean since then according to btrfsck.

The system appeared ok, but then I ran into trouble performing an
apt-get upgrade, which was unable to access some of its files due to a
stale NFS lock. I found no kernel messages in dmesg concerning that
matter, just this user-space error message. An offline check of the
root file system (booting from USB live system) showed up some errors.
Btrfsck wasn't able to repair them and segfaulted. I reinstalled the
system now.

Btrfsck on the root fs:
https://docs.google.com/file/d/0B7RIDdXgzUrqTUczWHZYejUzMWM/edit?usp=sharing
Btrfs-image of the root fs:
https://docs.google.com/file/d/0B7RIDdXgzUrqV3hEZ1BZX0lhbVk/edit?usp=sharing

Kernel-bug when mounting the home fs:
https://docs.google.com/file/d/0B7RIDdXgzUrqTGFneGdCM0FBYzg/edit?usp=sharing
Btrfsck on the home fs:
https://docs.google.com/file/d/0B7RIDdXgzUrqODVhUUhqa2Q4c0k/edit?usp=sharing
Btrfs-zero-log on home fs:
https://docs.google.com/file/d/0B7RIDdXgzUrqM3ltTnBUVWMzdjg/edit?usp=sharing

I still have an image (dd and btrfs-image) of the broken homefs. If
this is of any use to you feel free to contact me via email.

Best regards,
Peter
--
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

[no subject]

2013-03-07 Thread David Sterba

Hi,

I'm seeing messages like this

[ 3194.928153] btrfs allocation failed flags 1, wanted 65536
[ 3194.934874] space_info 1 has 147456 free, is full
[ 3194.941205] space_info total=1903427584, used=1903280128, pinned=0, 
reserved=0, may_use=65536, readonly=0
[ 3194.941209] block group 12582912 has 8388608 bytes, 8376320 used 0 pinned 0 
reserved 
[ 3194.941212] entry offset 20959232, bytes 12288, bitmap no
[ 3194.941213] block group has cluster?: no
[ 3194.941215] 0 blocks of free space at or bigger than bytes is
[ 3194.941218] block group 136708096 has 218103808 bytes, 218095616 used 0 
pinned 0 reserved 
[ 3194.941221] entry offset 354803712, bytes 8192, bitmap no
[ 3194.941222] block group has cluster?: no

mkfs is default, mount with noatime, happens consistently at
xfstests/275 (on first run of the whole testsuite) the test uses a 2g
scratch partition.

Has been observed for like 2 weeks when testing next/master.

The test description says

# The posix write test.  When write size is larger than disk free size,
# should write as much as possible until ENOSPC.

so enospc messages can be expected, although I don't know if they're
just debugging or point to real bugs.

Full log attached.

david
Mar  7 14:53:16 root: run xfstest 275
Mar  7 14:53:17 kernel: [ 3153.309687] device fsid 
1cc979d6-c415-4607-bcfd-71efd34bf3ef devid 1 transid 4 /dev/sda9
Mar  7 14:53:17 kernel: [ 3153.359752] device fsid 
1cc979d6-c415-4607-bcfd-71efd34bf3ef devid 1 transid 4 /dev/sda9
Mar  7 14:53:17 kernel: [ 3153.371696] btrfs: disk space caching is enabled
Mar  7 14:53:58 kernel: [ 3194.928153] btrfs allocation failed flags 1, wanted 
65536
Mar  7 14:53:58 kernel: [ 3194.934874] space_info 1 has 147456 free, is full
Mar  7 14:54:02 kernel: [ 3194.941205] space_info total=1903427584, 
used=1903280128, pinned=0, reserved=0, may_use=65536, readonly=0
Mar  7 14:54:02 kernel: [ 3194.941209] block group 12582912 has 8388608 bytes, 
8376320 used 0 pinned 0 reserved 
Mar  7 14:54:02 kernel: [ 3194.941212] entry offset 20959232, bytes 12288, 
bitmap no
Mar  7 14:54:02 kernel: [ 3194.941213] block group has cluster?: no
Mar  7 14:54:02 kernel: [ 3194.941215] 0 blocks of free space at or bigger than 
bytes is
Mar  7 14:54:02 kernel: [ 3194.941218] block group 136708096 has 218103808 
bytes, 218095616 used 0 pinned 0 reserved 
Mar  7 14:54:02 kernel: [ 3194.941221] entry offset 354803712, bytes 8192, 
bitmap no
Mar  7 14:54:02 kernel: [ 3194.941222] block group has cluster?: no
Mar  7 14:54:02 kernel: [ 3194.941224] 0 blocks of free space at or bigger than 
bytes is
Mar  7 14:54:02 kernel: [ 3194.941227] block group 354811904 has 218103808 
bytes, 218091520 used 0 pinned 0 reserved 
Mar  7 14:54:02 kernel: [ 3194.941229] entry offset 572903424, bytes 12288, 
bitmap no
Mar  7 14:54:02 kernel: [ 3194.941230] block group has cluster?: no
Mar  7 14:54:02 kernel: [ 3194.941232] 0 blocks of free space at or bigger than 
bytes is
Mar  7 14:54:02 kernel: [ 3194.941235] block group 572915712 has 218103808 
bytes, 218071040 used 0 pinned 0 reserved 
Mar  7 14:54:02 kernel: [ 3194.941237] entry offset 790986752, bytes 32768, 
bitmap no
Mar  7 14:54:02 kernel: [ 3194.941238] block group has cluster?: no
Mar  7 14:54:02 kernel: [ 3194.941239] 0 blocks of free space at or bigger than 
bytes is
Mar  7 14:54:02 kernel: [ 3194.941243] block group 791019520 has 218103808 
bytes, 218103808 used 0 pinned 0 reserved 
Mar  7 14:54:02 kernel: [ 3194.941248] block group has cluster?: no
Mar  7 14:54:02 kernel: [ 3194.941249] 0 blocks of free space at or bigger than 
bytes is
Mar  7 14:54:02 kernel: [ 3194.941253] block group 1009123328 has 218103808 
bytes, 218103808 used 0 pinned 0 reserved 
Mar  7 14:54:02 kernel: [ 3194.941254] block group has cluster?: no
Mar  7 14:54:02 kernel: [ 3194.941255] 0 blocks of free space at or bigger than 
bytes is
Mar  7 14:54:02 kernel: [ 3194.941259] block group 1227227136 has 218103808 
bytes, 218087424 used 0 pinned 0 reserved 
Mar  7 14:54:02 kernel: [ 3194.941261] entry offset 1445314560, bytes 16384, 
bitmap no
Mar  7 14:54:02 kernel: [ 3194.941262] block group has cluster?: no
Mar  7 14:54:02 kernel: [ 3194.941264] 0 blocks of free space at or bigger than 
bytes is
Mar  7 14:54:02 kernel: [ 3194.941267] block group 1445330944 has 218103808 
bytes, 218083328 used 0 pinned 0 reserved 
Mar  7 14:54:02 kernel: [ 3194.941269] entry offset 1663414272, bytes 20480, 
bitmap no
Mar  7 14:54:02 kernel: [ 3194.941270] block group has cluster?: no
Mar  7 14:54:02 kernel: [ 3194.941272] 0 blocks of free space at or bigger than 
bytes is
Mar  7 14:54:02 kernel: [ 3194.941275] block group 1663434752 has 218103808 
bytes, 218079232 used 0 pinned 0 reserved 
Mar  7 14:54:02 kernel: [ 3194.941277] entry offset 1881513984, bytes 24576, 
bitmap no
Mar  7 14:54:02 kernel: [ 3194.941278] block group has cluster?: no
Mar  7 14:54:02 kernel: [ 3194.941280] 0 blocks of free space at or bigger than 
bytes is
Mar  7 14:54:02 kernel: [

[no subject]

2013-02-03 Thread Michael Raskin

I have an btrfs-image of corrupted BtrFS partition

After btrfsck --repair, mount failed with segfault both before and after

No subvolumes

http://dev.mccme.ru/~raskin/btrfs.corruption.img.gz

[   41.169414] device label home-corrupted devid 1 transid 398696 /dev/sda
[   41.170974] btrfs: disk space caching is enabled
[   41.189699] btrfs: mismatching generation and generation_v2 found in root 
item. This root was probably mounted with an older kernel. Resetting all new 
fields.
[   41.433117] parent transid verify failed on 88661934080 wanted 398697 found 
398691
[   41.451047] parent transid verify failed on 88661934080 wanted 398697 found 
398691
[   41.498321] [ cut here ]
[   41.498326] kernel BUG at fs/btrfs/tree-log.c:1922!
[   41.498328] invalid opcode:  [#1] SMP 
[   41.498331] Modules linked in: ppdev parport_pc i2c_piix4 i2c_core parport 
microcode raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor 
async_memcpy async_tx raid1 raid0 multipath linear 8139cp 8139too mii
[   41.498347] CPU 0 
[   41.498350] Pid: 1580, comm: mount Not tainted 3.7.4-alt330-amd64 #2 Bochs 
Bochs
[   41.498352] RIP: 0010:[813ad1e2]  [813ad1e2] 
replay_one_buffer+0x141/0x29b
[   41.498366] RSP: :880006fcf928  EFLAGS: 00010286
[   41.498367] RAX: ffe4 RBX: 880006fcfaa8 RCX: 6000
[   41.498369] RDX: 0008 RSI: 0020 RDI: 
[   41.498370] RBP: 880006fcf9a8 R08: ffe4 R09: 880006fcf6c8
[   41.498371] R10: 0001 R11: 880006fcf958 R12: 880001f30560
[   41.498373] R13:  R14: 880002a7d120 R15: 880002b78000
[   41.498374] FS:  () GS:88000720(0063) 
knlGS:f757d700
[   41.498376] CS:  0010 DS: 002b ES: 002b CR0: 8005003b
[   41.498377] CR2: 083a3bb0 CR3: 053f3000 CR4: 06f0
[   41.498381] DR0:  DR1:  DR2: 
[   41.498385] DR3:  DR6: 0ff0 DR7: 0400
[   41.498386] Process mount (pid: 1580, threadinfo 880006fce000, task 
88a0ae00)
[   41.498387] Stack:
[   41.498388]  1000 1000 1600 
0009
[   41.498391]  880002b79800 8000 0090b0ad 
0001
[   41.498393]   880006fcfa54 880002a7d090 
880006fcfa54
[   41.498395] Call Trace:
[   41.498402]  [813a7e45] walk_down_log_tree+0x1a9/0x35e
[   41.498404]  [813a8265] walk_log_tree+0x99/0x1ce
[   41.498407]  [813aa32c] btrfs_recover_log_trees+0x205/0x31b
[   41.498409]  [813ad0a1] ? add_inode_ref+0x80e/0x80e
[   41.498412]  [8137df3b] open_ctree+0x1492/0x184f
[   41.498419]  [8135f269] btrfs_mount+0x382/0x525
[   41.498429]  [810fe530] ? pcpu_next_pop+0x38/0x45
[   41.498431]  [810ff5a4] ? pcpu_alloc+0x87b/0x8c5
[   41.498438]  [8114cbef] ? alloc_vfsmnt+0x9e/0x187
[   41.498444]  [811380d9] mount_fs+0x6b/0x14f
[   41.498447]  [810ff609] ? __alloc_percpu+0xb/0xd
[   41.498449]  [8114e34d] vfs_kern_mount+0x62/0xcf
[   41.498451]  [8114e42b] do_kern_mount+0x48/0xd8
[   41.498453]  [8114ebad] do_mount+0x6f2/0x755
[   41.498456]  [810fb4ff] ? memdup_user+0x48/0x68
[   41.498459]  [810fb558] ? strndup_user+0x39/0x4e
[   41.498463]  [81171577] compat_sys_mount+0x213/0x24d
[   41.498467]  [8170c729] ia32_do_call+0x13/0x13
[   41.498468] Code: fe e8 51 c9 ff ff 85 c0 74 04 0f 0b eb fe 48 8b 7b 20 4c 
8d 4d b0 45 89 e8 4c 89 e1 4c 89 f2 4c 89 fe e8 1c dc ff ff 85 c0 74 04 0f 0b 
eb fe 81 7d ac 00 80 00 00 75 18 48 8b 7b 20 48 8b 55 b0 
[   41.498484] RIP  [813ad1e2] replay_one_buffer+0x141/0x29b
[   41.498486]  RSP 880006fcf928
[   41.498489] ---[ end trace b03c7e7060c0017c ]---

-o recovery,ro didn't help

btrfs-zero-log didn't help

-o recovery,ro,clear_cache after btrfs-zero-log worked

Is the image of any use or should I just delete it?

Thanks
Michael Raskin



--
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

[no subject]

2013-02-01 Thread Kiran Patil

subscribe
--
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

[no subject]

2012-12-07 Thread merc1984


We're using a backups server to back up all machines in a LAN.  Four 2TB
disks are assembled in a BTRFS RAID array and mounted as /media/backups.
 Under this are subvolumes droog, hex, etc, and snapshots
droog_snap-{date1}, hex_snap-{date1}, etc.

Goal is to encrypt backups, but the concern is with snapshots.  Won't
piping rsync through encryption with GPG or somesuch, play havoc with
BTRFS snapshot accounting?

Is there any way to encrypt an array so it is inaccesible while
umounted?

I've already asked on the ecryptfs listserv and it resulted in mass
confusion.

-- 
http://www.fastmail.fm - A fast, anti-spam email service.

--
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

[no subject]

2012-12-03 Thread Ernest Wilson


REF No: L/200-26937
BATCH No: 2007MJL-01


Your e-mail address have won you 750,000 GBP in Microsoft end of year raffle 
draw award 2012, contact this email : (ernestwilson...@zhot.net)with your 
name,address,phone number and age.

Regards,
Ernest Wilson.


--
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

[no subject]

2012-08-29 Thread Chris Mason

Hi Linus,

I've split out the big send/receive update from my last pull request and
now have just the fixes in my for-linus branch:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus

For anyone who wants send/receive updates, they are maintained as well.
But it is has enough cleanups (without fixes) that we shouldn't be asking
Linus to take it right now.  The send/recv branch will wander over to
linux-next shortly though.

git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git send-recv

The largest patches in this pull are Josef's patches to fix DIO locking
problems and his patch to fix a crash during balance.
They are both well tested.

The rest are smaller fixes that we've had queued.  The last rc came out
while I was hacking new and exciting ways to recover from a misplaced rm
-rf on my dev box, so these missed rc3.

Josef Bacik (9) commits (+322/-216):
Btrfs: don't allocate a seperate csums array for direct reads (+19/-32)
Btrfs: do not use missing devices when showing devname (+2/-0)
Btrfs: fix enospc problems when deleting a subvol (+1/-1)
Btrfs: increase the size of the free space cache (+7/-8)
Btrfs: lock extents as we map them in DIO (+127/-129)
Btrfs: fix deadlock with freeze and sync V2 (+9/-4)
Btrfs: allow delayed refs to be merged (+142/-27)
Btrfs: do not strdup non existent strings (+5/-3)
Btrfs: barrier before waitqueue_active (+10/-12)

Stefan Behrens (5) commits (+16/-77):
Btrfs: fix that repair code is spuriously executed for transid failures 
(+6/-2)
Btrfs: revert checksum error statistic which can cause a BUG() (+2/-39)
Btrfs: fix a misplaced address operator in a condition (+1/-1)
Btrfs: remove superblock writing after fatal error (+5/-33)
Btrfs: fix that error value is changed by mistake (+2/-2)

Dan Carpenter (4) commits (+16/-8):
Btrfs: unlock on error in btrfs_delalloc_reserve_metadata() (+3/-1)
Btrfs: fix some error codes in btrfs_qgroup_inherit() (+6/-2)
Btrfs: fix some endian bugs handling the root times (+4/-4)
Btrfs: checking for NULL instead of IS_ERR (+3/-1)

Liu Bo (2) commits (+25/-6):
Btrfs: fix ordered extent leak when failing to start a transaction (+5/-2)
Btrfs: fix a dio write regression (+20/-4)

Arne Jansen (2) commits (+38/-73):
Btrfs: fix deadlock in wait_for_more_refs (+21/-73)
Btrfs: fix race in run_clustered_refs (+17/-0)

Chris Mason (1) commits (+3/-0):
Btrfs: don't run __tree_mod_log_free_eb on leaves

Fengguang Wu (1) commits (+3/-2):
btrfs: fix second lock in btrfs_delete_delayed_items()

Miao Xie (1) commits (+1/-0):
Btrfs: fix wrong mtime and ctime when creating snapshots

Total: (25) commits (+424/-382)

 fs/btrfs/backref.c   |   4 +-
 fs/btrfs/compression.c   |   1 +
 fs/btrfs/ctree.c |   9 +-
 fs/btrfs/ctree.h |   3 +-
 fs/btrfs/delayed-inode.c |  12 +-
 fs/btrfs/delayed-ref.c   | 163 +++-
 fs/btrfs/delayed-ref.h   |   4 +
 fs/btrfs/disk-io.c   |  53 ++--
 fs/btrfs/disk-io.h   |   2 +-
 fs/btrfs/extent-tree.c   | 123 +-
 fs/btrfs/extent_io.c |  17 +--
 fs/btrfs/file-item.c |   4 +-
 fs/btrfs/inode.c | 326 ---
 fs/btrfs/ioctl.c |   2 +-
 fs/btrfs/locking.c   |   2 +-
 fs/btrfs/qgroup.c|  12 +-
 fs/btrfs/root-tree.c |   4 +-
 fs/btrfs/super.c |  15 ++-
 fs/btrfs/transaction.c   |   3 +-
 fs/btrfs/volumes.c   |  33 +
 fs/btrfs/volumes.h   |   2 -
 21 files changed, 418 insertions(+), 376 deletions(-)
--
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

[no subject]

2012-08-17 Thread David Sterba

On Fri, Aug 17, 2012 at 09:45:20AM +0800, Liu Bo wrote:
 On 08/15/2012 06:12 PM, Lluís Batlle i Rossell wrote:
  some time ago we discussed on #btrfs that the nocow attribute for files 
  wasn't
  working (around 3.3 or 3.4 kernels). That was evident by files fragmenting 
  even
  with the attribute set.
  
  Chris mentioned to find a fix quickly for that, and posted some lines of 
  change
  into irc. But recently someone mentioned that 3.6-rc looks like still not
  respecting nocow for files.
  
  Is there really a fix upstream for that? Do nocow attribute on files work 
  for
  anyone already?
  
 
 Dave had post a patch to fix it but only enabling NOCOW with zero sized file.
 
 FYI, the patch is http://article.gmane.org/gmane.comp.file-systems.btrfs/17351
 
 With the patch, you don't need to mount with nodatacow any more :)
 
 And why it is only for only zero sized file:
 http://permalink.gmane.org/gmane.comp.file-systems.btrfs/18046

the original patch 
http://permalink.gmane.org/gmane.comp.file-systems.btrfs/18031
did two things, the reasoning why it is not allowed to set nodatasum in
general applies only to the second hunk but this

@@ -139,7 +139,7 @@ void btrfs_inherit_iflags(struct inode *inode, struct inode 
*dir)
}

if (flags  BTRFS_INODE_NODATACOW)
-   BTRFS_I(inode)-flags |= BTRFS_INODE_NODATACOW;
+   BTRFS_I(inode)-flags |= BTRFS_INODE_NODATACOW | 
BTRFS_INODE_NODATASUM;

btrfs_update_iflags(inode);
 }
---

is sufficient to create nocow files via a directory with NOCOW attribute
set, and all new files will inherit it (they are automatically
zero-sized so it's safe). This usecase is similar to setting the
COMPRESS attribute on a directory and all new files will inherit the
flag.

If Andrei wants to resend just this particular hunk, I'm giving it my ACK.


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

[no subject]

2012-05-02 Thread Henrik Kuhn


auth d55b8112 subscribe linux-btrfshenrik.k...@origenis.de

attachment: henrik_kuhn.vcf

[no subject]

2011-10-29 Thread Kai Moonbourn


help
--
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

[no subject]

2011-09-20 Thread Ken D'Ambrosio

Just wondering if/how one goes about getting the btrfs checksum of a given
file.  Is there a way?

Thanks!

-Ken





--
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

[no subject]

2011-09-01 Thread Ivan Piazza

unscribe linux-btrfs
--
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

[no subject]

2011-07-01 Thread Edward Goggin

subscribe linux-btrfs--
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

[RFC][PATCH 2/2] Subject: btrfs: Introduce btrfs_get_maps_dev()

2011-05-13 Thread Mark Fasheh

Use this to return the subvolume superblock in proc instead of the global
superblock which is automatically taken today. This fixes a userspace
breakage where discrepancies between the devices two would confuse software
such as lsof.

Signed-off-by: Mark Fasheh mfas...@suse.com
---
 fs/btrfs/super.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 58e7de9..d241fb0 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1115,6 +1115,11 @@ static int btrfs_unfreeze(struct super_block *sb)
return 0;
 }
 
+static dev_t btrfs_get_maps_dev(struct inode *inode)
+{
+   return BTRFS_I(inode)-root-anon_super.s_dev;
+}
+
 static const struct super_operations btrfs_super_ops = {
.drop_inode = btrfs_drop_inode,
.evict_inode= btrfs_evict_inode,
@@ -1129,6 +1134,7 @@ static const struct super_operations btrfs_super_ops = {
.remount_fs = btrfs_remount,
.freeze_fs  = btrfs_freeze,
.unfreeze_fs= btrfs_unfreeze,
+   .get_maps_dev   = btrfs_get_maps_dev,
 };
 
 static const struct file_operations btrfs_ctl_fops = {
-- 
1.6.4.2

--
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 1/2] Subject: mutex: Separate out mutex_spin()

2011-03-24 Thread Tejun Heo

Separate out mutex_spin() out of __mutex_lock_common().  The fat
comment is converted to docbook function description.

While at it, drop the part of comment which explains that adaptive
spinning considers whether there are pending waiters, which doesn't
match the code.

This patch is to prepare for using adaptive spinning in
mutex_trylock() and doesn't cause any behavior change.

Signed-off-by: Tejun Heo t...@kernel.org
LKML-Reference: 20110323153727.gb12...@htj.dyndns.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Ingo Molnar mi...@redhat.com
---
Here are split patches with SOB.  Ingo, it's probably best to route
this through -tip, I suppose?

Thanks.

 kernel/mutex.c |   87 -
 1 file changed, 50 insertions(+), 37 deletions(-)

Index: work/kernel/mutex.c
===
--- work.orig/kernel/mutex.c
+++ work/kernel/mutex.c
@@ -126,39 +126,32 @@ void __sched mutex_unlock(struct mutex *
 
 EXPORT_SYMBOL(mutex_unlock);
 
-/*
- * Lock a mutex (possibly interruptible), slowpath:
+/**
+ * mutex_spin - optimistic spinning on mutex
+ * @lock: mutex to spin on
+ *
+ * This function implements optimistic spin for acquisition of @lock when
+ * the lock owner is currently running on a (different) CPU.
+ *
+ * The rationale is that if the lock owner is running, it is likely to
+ * release the lock soon.
+ *
+ * Since this needs the lock owner, and this mutex implementation doesn't
+ * track the owner atomically in the lock field, we need to track it
+ * non-atomically.
+ *
+ * We can't do this for DEBUG_MUTEXES because that relies on wait_lock to
+ * serialize everything.
+ *
+ * CONTEXT:
+ * Preemption disabled.
+ *
+ * RETURNS:
+ * %true if @lock is acquired, %false otherwise.
  */
-static inline int __sched
-__mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
-   unsigned long ip)
+static inline bool mutex_spin(struct mutex *lock)
 {
-   struct task_struct *task = current;
-   struct mutex_waiter waiter;
-   unsigned long flags;
-
-   preempt_disable();
-   mutex_acquire(lock-dep_map, subclass, 0, ip);
-
 #ifdef CONFIG_MUTEX_SPIN_ON_OWNER
-   /*
-* Optimistic spinning.
-*
-* We try to spin for acquisition when we find that there are no
-* pending waiters and the lock owner is currently running on a
-* (different) CPU.
-*
-* The rationale is that if the lock owner is running, it is likely to
-* release the lock soon.
-*
-* Since this needs the lock owner, and this mutex implementation
-* doesn't track the owner atomically in the lock field, we need to
-* track it non-atomically.
-*
-* We can't do this for DEBUG_MUTEXES because that relies on wait_lock
-* to serialize everything.
-*/
-
for (;;) {
struct thread_info *owner;
 
@@ -177,12 +170,8 @@ __mutex_lock_common(struct mutex *lock,
if (owner  !mutex_spin_on_owner(lock, owner))
break;
 
-   if (atomic_cmpxchg(lock-count, 1, 0) == 1) {
-   lock_acquired(lock-dep_map, ip);
-   mutex_set_owner(lock);
-   preempt_enable();
-   return 0;
-   }
+   if (atomic_cmpxchg(lock-count, 1, 0) == 1)
+   return true;
 
/*
 * When there's no owner, we might have preempted between the
@@ -190,7 +179,7 @@ __mutex_lock_common(struct mutex *lock,
 * we're an RT task that will live-lock because we won't let
 * the owner complete.
 */
-   if (!owner  (need_resched() || rt_task(task)))
+   if (!owner  (need_resched() || rt_task(current)))
break;
 
/*
@@ -202,6 +191,30 @@ __mutex_lock_common(struct mutex *lock,
arch_mutex_cpu_relax();
}
 #endif
+   return false;
+}
+
+/*
+ * Lock a mutex (possibly interruptible), slowpath:
+ */
+static inline int __sched
+__mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
+   unsigned long ip)
+{
+   struct task_struct *task = current;
+   struct mutex_waiter waiter;
+   unsigned long flags;
+
+   preempt_disable();
+   mutex_acquire(lock-dep_map, subclass, 0, ip);
+
+   if (mutex_spin(lock)) {
+   lock_acquired(lock-dep_map, ip);
+   mutex_set_owner(lock);
+   preempt_enable();
+   return 0;
+   }
+
spin_lock_mutex(lock-wait_lock, flags);
 
debug_mutex_lock_common(lock, waiter);
--
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: [PATCH 1/2] Subject: mutex: Separate out mutex_spin()

2011-03-24 Thread Tejun Heo

Ugh... Please drop the extra Subject:  from subject before applying.
Thanks.

-- 
tejun
--
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

[no subject]

2010-11-12 Thread hugo

From 2de353ddda78ef5cbc84e1d3267606bc44e48faa Mon Sep 17 00:00:00 2001
Message-Id: 
2de353ddda78ef5cbc84e1d3267606bc44e48faa.1289589812.git.h...@carfax.org.uk
From: Hugo Mills h...@carfax.org.uk
Date: Sat, 6 Nov 2010 00:18:12 +
Subject: [PATCH] Clean up typography in the man pages.
To: linux-btrfs@vger.kernel.org
Cc: Goffredo Baroncelli kreij...@libero.it

The man pages are a bit vague about their use of bold and italic, and
don't lay out the meaning of options for each command very well. This
patch tightens up on the type-styles and layout for the main man pages
(btrfs, btrfsck, mkfs.btrfs).

Signed-off-by: Hugo Mills h...@carfax.org.uk
---
 man/btrfs.8.in  |  270 +-
 man/btrfsck.8.in|4 +-
 man/mkfs.btrfs.8.in |   39 
 3 files changed, 200 insertions(+), 113 deletions(-)

diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 26ef982..7569a9e 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -1,39 +1,73 @@
+.so an
 .TH BTRFS 8  btrfs btrfs
 .\
 .\ Man page written by Goffredo Baroncelli kreij...@inwind.it (Feb 2010)
+.\ Typography fixed by Hugo Mills h...@carfax.org.uk (Oct 2010)
 .\
 .SH NAME
 btrfs \- control a btrfs filesystem
 .SH SYNOPSIS
-\fBbtrfs\fP \fBsubvolume snapshot\fP\fI source [dest/]name\fP
+\fBsubvolume snapshot \fIsource \fR[\fIdest\fR] \fIname\fR
 .PP
-\fBbtrfs\fP \fBsubvolume delete\fP\fI subvolume\fP
+
+.BI btrfs subvolume delete  subvolume
+.PP
+
+.B btrfs subvolume create
+.RI [ dest ]  name
 .PP
-\fBbtrfs\fP \fBsubvolume create\fP\fI [dest/]name\fP
+
+.BI btrfs subvolume list  path
+.PP
+
+.BI btrfs subvolume set-default  id path
 .PP
-\fBbtrfs\fP \fBsubvolume list\fP\fI path\fP
+
+.B btrfs filesystem defragment 
+.RB [ -vcf ] [ -s
+.IR start ]
+.RB [ -l
+.IR len ]
+.RB [ -t
+.IR size ]  file | dir  ...
 .PP
-\fBbtrfs\fP \fBsubvolume set-default\fP\fI id path\fP
+
+.BI btrfs filesystem sync  path
 .PP
-\fBbtrfs\fP \fBfilesystem defrag\fP\fI file|dir [file|dir...]\fP
+
+.BR btrfs filesystem resize  [ + | \- ] \fIsize\fP [ gmk ]| max
+.I filesystem
 .PP
-\fBbtrfs\fP \fBfilesystem sync\fP\fI path \fP
+
+.BR btrfs filesystem df  [ -h | --human-readable | -H | --si ]
++.I path
 .PP
-\fBbtrfs\fP \fBfilesystem resize\fP\fI [+/\-]size[gkm]|max filesystem\fP
+
+.BR btrfs filesystem show  [ -h | --human-readable | -H | --si ]
+.RI [ uuid | label ]
 .PP
-\fBbtrfs\fP \fBdevice scan\fP\fI [device [device..]]\fP
+.B btrfs device scan
+.RI [ device ]  ...
 .PP
-\fBbtrfs\fP \fBdevice show\fP\fI dev|label [dev|label...]\fP
+
+.B btrfs device show
+.IR dev | label  ...
 .PP
-\fBbtrfs\fP \fBdevice balance\fP\fI path \fP
+
+.BI btrfs device balance  path
 .PP
-\fBbtrfs\fP \fBdevice add\fP\fI dev [dev..] path \fP
+
+.BI btrfs device add  dev
+.RI [ dev  ... ] path
 .PP
-\fBbtrfs\fP \fBdevice delete\fP\fI dev [dev..] path \fP]
 
+.B btrfs device delete
+.IR dev [ dev  ... ] path
 .PP
-\fBbtrfs\fP \fBhelp|\-\-help|\-h \fP\fI\fP
+
+.BR btrfs help | \-\-help | \-h
 .PP
+
 .SH DESCRIPTION
 .B btrfs
 is used to control the filesystem and the files and directories stored. It is
@@ -42,123 +76,174 @@ filesystem, to defrag a file or a directory, flush the 
data to the disk,
 to resize the filesystem, to scan the device.
 
 It is possible to abbreviate the commands unless the commands  are ambiguous.
-For example: it is possible to run
-.I btrfs sub snaps
+For example, it is possible to run
+.B btrfs sub snaps
 instead of
-.I btrfs subvolume snapshot.
+.B btrfs subvolume snapshot.
 But
-.I btrfs dev s
+.B btrfs dev s
 is not allowed, because
-.I dev s
+.B dev s
 may be interpreted both as
-.I device show
+.B device show
 and as
-.I device scan.
+.B device scan.
 In this case
-.I btrfs
+.B btrfs
 returns an error.
 
 If a command is terminated by
-.I --help
-, the relevant help is showed. If the passed command matches more commands,
-the help of all the matched commands are showed. For example
-.I btrfs dev --help
+.B --help
+, the relevant help is shown. If the passed command matches more commands,
+the help of all the matched commands is shown. For example
+.B btrfs dev --help
 shows the help of all
-.I device*
-command.
+.B device*
+commands.
 
 .SH COMMANDS
-.TP
+.SS
+subvolume snapshot \fIsource \fR[\fIdest\fR] \fIname\fR
 
-\fBsubvolume snapshot\fR\fI source [dest/]name\fR
-Create a writable snapshot of the subvolume \fIsource\fR with the name
-\fIname\fR in the \fIdest\fR directory. If \fIsource\fR is not a
-subvolume, \fBbtrfs\fR returns an error.
-.TP
+Create a writable snapshot of the subvolume \fIsource\fP with the
+name \fIname\fP in the \fIdest\fP directory. If \fIsource\fP is
+not a subvolume, \fBbtrfs\fP returns an error.
 
-\fBsubvolume delete\fR\fI subvolume\fR
-Delete the subvolume \fIsubvolume\fR. If \fIsubvolume\fR is not a
-subvolume, \fBbtrfs\fR returns an error.
-.TP
+.SS
+subvolume delete \fIsubvolume\fP
 
-\fBsubvolume create\fR\fI [dest/]name\fR
-Create a subvolume in \fIdest\fR (or in the current directory if
-\fIdest

[no subject]

2010-11-12 Thread hugo

From 2de353ddda78ef5cbc84e1d3267606bc44e48faa Mon Sep 17 00:00:00 2001
Message-Id: 
2de353ddda78ef5cbc84e1d3267606bc44e48faa.1289589812.git.h...@carfax.org.uk
From: Hugo Mills h...@carfax.org.uk
Date: Sat, 6 Nov 2010 00:18:12 +
Subject: [PATCH] Clean up typography in the man pages.
To: linux-btrfs@vger.kernel.org
Cc: Goffredo Baroncelli kreij...@libero.it

The man pages are a bit vague about their use of bold and italic, and
don't lay out the meaning of options for each command very well. This
patch tightens up on the type-styles and layout for the main man pages
(btrfs, btrfsck, mkfs.btrfs).

Signed-off-by: Hugo Mills h...@carfax.org.uk
---
 man/btrfs.8.in  |  270 +-
 man/btrfsck.8.in|4 +-
 man/mkfs.btrfs.8.in |   39 
 3 files changed, 200 insertions(+), 113 deletions(-)

diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 26ef982..7569a9e 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -1,39 +1,73 @@
+.so an
 .TH BTRFS 8  btrfs btrfs
 .\
 .\ Man page written by Goffredo Baroncelli kreij...@inwind.it (Feb 2010)
+.\ Typography fixed by Hugo Mills h...@carfax.org.uk (Oct 2010)
 .\
 .SH NAME
 btrfs \- control a btrfs filesystem
 .SH SYNOPSIS
-\fBbtrfs\fP \fBsubvolume snapshot\fP\fI source [dest/]name\fP
+\fBsubvolume snapshot \fIsource \fR[\fIdest\fR] \fIname\fR
 .PP
-\fBbtrfs\fP \fBsubvolume delete\fP\fI subvolume\fP
+
+.BI btrfs subvolume delete  subvolume
+.PP
+
+.B btrfs subvolume create
+.RI [ dest ]  name
 .PP
-\fBbtrfs\fP \fBsubvolume create\fP\fI [dest/]name\fP
+
+.BI btrfs subvolume list  path
+.PP
+
+.BI btrfs subvolume set-default  id path
 .PP
-\fBbtrfs\fP \fBsubvolume list\fP\fI path\fP
+
+.B btrfs filesystem defragment 
+.RB [ -vcf ] [ -s
+.IR start ]
+.RB [ -l
+.IR len ]
+.RB [ -t
+.IR size ]  file | dir  ...
 .PP
-\fBbtrfs\fP \fBsubvolume set-default\fP\fI id path\fP
+
+.BI btrfs filesystem sync  path
 .PP
-\fBbtrfs\fP \fBfilesystem defrag\fP\fI file|dir [file|dir...]\fP
+
+.BR btrfs filesystem resize  [ + | \- ] \fIsize\fP [ gmk ]| max
+.I filesystem
 .PP
-\fBbtrfs\fP \fBfilesystem sync\fP\fI path \fP
+
+.BR btrfs filesystem df  [ -h | --human-readable | -H | --si ]
++.I path
 .PP
-\fBbtrfs\fP \fBfilesystem resize\fP\fI [+/\-]size[gkm]|max filesystem\fP
+
+.BR btrfs filesystem show  [ -h | --human-readable | -H | --si ]
+.RI [ uuid | label ]
 .PP
-\fBbtrfs\fP \fBdevice scan\fP\fI [device [device..]]\fP
+.B btrfs device scan
+.RI [ device ]  ...
 .PP
-\fBbtrfs\fP \fBdevice show\fP\fI dev|label [dev|label...]\fP
+
+.B btrfs device show
+.IR dev | label  ...
 .PP
-\fBbtrfs\fP \fBdevice balance\fP\fI path \fP
+
+.BI btrfs device balance  path
 .PP
-\fBbtrfs\fP \fBdevice add\fP\fI dev [dev..] path \fP
+
+.BI btrfs device add  dev
+.RI [ dev  ... ] path
 .PP
-\fBbtrfs\fP \fBdevice delete\fP\fI dev [dev..] path \fP]
 
+.B btrfs device delete
+.IR dev [ dev  ... ] path
 .PP
-\fBbtrfs\fP \fBhelp|\-\-help|\-h \fP\fI\fP
+
+.BR btrfs help | \-\-help | \-h
 .PP
+
 .SH DESCRIPTION
 .B btrfs
 is used to control the filesystem and the files and directories stored. It is
@@ -42,123 +76,174 @@ filesystem, to defrag a file or a directory, flush the 
data to the disk,
 to resize the filesystem, to scan the device.
 
 It is possible to abbreviate the commands unless the commands  are ambiguous.
-For example: it is possible to run
-.I btrfs sub snaps
+For example, it is possible to run
+.B btrfs sub snaps
 instead of
-.I btrfs subvolume snapshot.
+.B btrfs subvolume snapshot.
 But
-.I btrfs dev s
+.B btrfs dev s
 is not allowed, because
-.I dev s
+.B dev s
 may be interpreted both as
-.I device show
+.B device show
 and as
-.I device scan.
+.B device scan.
 In this case
-.I btrfs
+.B btrfs
 returns an error.
 
 If a command is terminated by
-.I --help
-, the relevant help is showed. If the passed command matches more commands,
-the help of all the matched commands are showed. For example
-.I btrfs dev --help
+.B --help
+, the relevant help is shown. If the passed command matches more commands,
+the help of all the matched commands is shown. For example
+.B btrfs dev --help
 shows the help of all
-.I device*
-command.
+.B device*
+commands.
 
 .SH COMMANDS
-.TP
+.SS
+subvolume snapshot \fIsource \fR[\fIdest\fR] \fIname\fR
 
-\fBsubvolume snapshot\fR\fI source [dest/]name\fR
-Create a writable snapshot of the subvolume \fIsource\fR with the name
-\fIname\fR in the \fIdest\fR directory. If \fIsource\fR is not a
-subvolume, \fBbtrfs\fR returns an error.
-.TP
+Create a writable snapshot of the subvolume \fIsource\fP with the
+name \fIname\fP in the \fIdest\fP directory. If \fIsource\fP is
+not a subvolume, \fBbtrfs\fP returns an error.
 
-\fBsubvolume delete\fR\fI subvolume\fR
-Delete the subvolume \fIsubvolume\fR. If \fIsubvolume\fR is not a
-subvolume, \fBbtrfs\fR returns an error.
-.TP
+.SS
+subvolume delete \fIsubvolume\fP
 
-\fBsubvolume create\fR\fI [dest/]name\fR
-Create a subvolume in \fIdest\fR (or in the current directory if
-\fIdest

[no subject]

2010-08-29 Thread Bret Palsson

subscribe linux-btrfs
--
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

[no subject]

2010-07-09 Thread jck

Hello,
when i check diskspace usage of a btrfs partition using df i get the
wrong free space, this is expected i think.
However even when i use 'btrfs filesystem df' I get wrong freespace:
Data: total=123.58GB, used=87.31GB
Metadata: total=61.00GB, used=396.29MB
System: total=32.00MB, used=16.00KB

Does this mean that after the 123 GB of 'Data' fills up I wont be able
to add more stuff to the partition?
I'm using btrfs-progs-git (jul 10)
--
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

[no subject]

2010-04-30 Thread Ilya Shestopalov

Bug message:
Btrfs loaded
device fsid 694983118c1865e7-ed2ca7537412e6ae devid 1 transid 73188 /dev/sda5
[ cut here ]
kernel BUG at fs/btrfs/tree-log.c:809!
invalid opcode:  [#1] PREEMPT SMP 
last sysfs file: 
/sys/devices/pci:00/:00:1f.2/host3/target3:0:0/3:0:0:0/scsi_level
Modules linked in: btrfs zlib_deflate crc32c libcrc32c fuse usbhid hid 
snd_hda_codec_analog snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq 
snd_seq_device snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd 
soundcore snd_page_alloc rtc_cmos rtc_core rtc_lib uhci_hcd asus_atk0110 
nvidia(P) agpgart firewire_ohci firewire_core crc_itu_t ehci_hcd usbcore 
i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support thermal button processor sky2 
x38_edac edac_core sg evdev pcspkr ext4 mbcache jbd2 crc16 sr_mod sd_mod cdrom 
floppy pata_jmicron ata_piix pata_acpi ata_generic libata scsi_mod

Pid: 2889, comm: mount Tainted: P   2.6.33-ARCH #1 P5E/P5E
EIP: 0060:[f9f468b9] EFLAGS: 00010246 CPU: 1
EIP is at add_inode_ref+0x3e9/0x400 [btrfs]
EAX:  EBX: 0097 ECX:  EDX: 00a9
ESI: 0002 EDI: f6ea4b40 EBP: f69e9c40 ESP: f69e9be4
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process mount (pid: 2889, ti=f69e8000 task=f653e1a0 task.ti=f69e8000)
Stack:
 f69e9bf8 f69e9bf8 c102ade0 f6ea4b40 0011 f69e9c00 f9f3991c f69e9c40
0 f9f2e36f f69e9c30  f6ea5000 f6df83dc 0004  f6ea4b40
0 f681 f6810800 fffa3000 fffa3000 0097 0002 f6ea4b40 f69e9ca4
Call Trace:
 [c102ade0] ? kunmap_atomic+0x70/0x80
 [f9f3991c] ? unmap_extent_buffer+0xc/0x10 [btrfs]
 [f9f2e36f] ? btrfs_item_size+0xdf/0xf0 [btrfs]
 [f9f477fe] ? replay_one_buffer+0x23e/0x310 [btrfs]
 [f9f44d70] ? walk_down_log_tree+0x210/0x510 [btrfs]
 [f9f45111] ? walk_log_tree+0xa1/0x1c0 [btrfs]
 [f9f4962b] ? btrfs_recover_log_trees+0x1cb/0x290 [btrfs]
 [f9f475c0] ? replay_one_buffer+0x0/0x310 [btrfs]
 [f9f14f58] ? open_ctree+0x10b8/0x15d0 [btrfs]
 [c1185249] ? strlcpy+0x39/0x50
 [f9ef8760] ? btrfs_get_sb+0x310/0x3f0 [btrfs]
 [c10ed24a] ? __alloc_percpu+0xa/0x10
 [c110be56] ? alloc_vfsmnt+0xe6/0x140
 [c10f69b1] ? vfs_kern_mount+0x61/0x1b0
 [c110ac87] ? get_fs_type+0x97/0xb0
 [c10f6b59] ? do_kern_mount+0x39/0xe0
 [c110d398] ? do_mount+0x358/0x700
 [c10cf0c4] ? strndup_user+0x44/0x80
 [c110d9e6] ? sys_mount+0x66/0xa0
 [c100371f] ? sysenter_do_call+0x12/0x28
Code: 8b 45 e4 e8 ca 39 fb ff 8b 45 d4 e8 e2 15 1c c7 8b 45 cc e8 da 15 1c c7 
31 c0 83 c4 50 5b 5e 5f 5d c3 b8 fe ff ff ff eb f1 0f 0b 0f 0b 0f 0b 0f 0b 0f 
0b 0f 0b 0f 0b 8d 74 26 00 8d bc 27 00 00 
EIP: [f9f468b9] add_inode_ref+0x3e9/0x400 [btrfs] SS:ESP 0068:f69e9be4
---[ end trace 1d3c13495ff7bd0e ]---


--
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

[no subject]

2010-04-14 Thread Jay Sullivan

subscribe linux-btrfs
--
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

[no subject]

2010-03-17 Thread dm


--
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

68 matches

Mail list logo