Re: [[Missing subject]]
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]
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]
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]
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]
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]
subscribe linux-btrfs
[no subject]
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]
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]
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]
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
>> 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
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
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]
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]
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]
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]
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]
subscribe linux-btrfs
[no subject]
subscribe linux-btrfs
Subject: [PATCH 2/3 v2] Prevent attempt to insert extent record with max_size==0
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]
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]
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
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
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
Посмотреть цены и ассортимент 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]
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]
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)
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]
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]
-- 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]
-- 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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
auth d55b8112 subscribe linux-btrfshenrik.k...@origenis.de attachment: henrik_kuhn.vcf
[no subject]
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]
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]
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]
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()
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()
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()
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]
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]
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]
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]
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]
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]
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]
-- 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