[PATCH] btrfs-progs: makefile: drop u option from ar invocation
In newer distros (ubuntu 15.10, fedora rawhide) the binutils ar uses the new D flag per default to build deterministic binaries. Without this patch the following warning is issued, when building btrfs-progs: [AR] libbtrfs.a /usr/bin/ar: `u' modifier ignored since `D' is the default (see `U') For libtrfs.a performance benefit of the u option can be neglected, so drop the u option and silence the warning. In the future one might want to explicitly add the D option anyway. Signed-off-by: Arnd Hannemann --- Makefile.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.in b/Makefile.in index 665f83c..514a76f 100644 --- a/Makefile.in +++ b/Makefile.in @@ -199,7 +199,7 @@ $(libs_shared): $(libbtrfs_objects) $(lib_links) send.h $(libs_static): $(libbtrfs_objects) @echo "[AR] $@" - $(Q)$(AR) cru libbtrfs.a $(libbtrfs_objects) + $(Q)$(AR) cr libbtrfs.a $(libbtrfs_objects) $(lib_links): @echo "[LN] $@" -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: severe hardlink bug
Am 29.07.2012 21:13, schrieb C Anthony Risinger: > On Sun, Jul 29, 2012 at 2:02 PM, Konstantin Dmitriev > wrote: >> Dipl.-Ing. Michael Niederle gmx.at> writes: >> >>> I reinstalled over 700 packages - plt-scheme beeing the only one failing >>> due to >>> the btrfs link restriction. >>> >> >> I have hit the same issue - tried to run BackupPC with a pool on btrfs >> filesystem. After some time the error of "too many links (31)" appeared to >> me. >> Now I'm forced to migrate to some other filesystem... > > btrfs only fails when you have hundreds of hardlinks to the same file > in the *same* directory ... certainly not a standard use case. Actually, "hundreds of hardlinks" is certainly over optimistic. In my testing 15 links in the same directory were enough to get the "Too many links" error. It depends on the length of the file name of the hardlinks. Best regards Arnd -- 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: 3.5.0-rc6: btrfs and LVM snapshots -> wrong devicename in /proc/mounts
Hi Goffredo, Am 10.07.2012 20:42, schrieb Goffredo Baroncelli: > Hi Arnd, > > I am trying to reproduce this bug. Which kernel version are you using ? I'm using linus' vanilla tree from Sunday which is 3.5.0-rc6 plus some unsuspicious commits. Best regards Arnd -- 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: 3.5.0-rc6: btrfs and LVM snapshots -> wrong devicename in /proc/mounts
Am 10.07.2012 00:49, schrieb cwillu: > On Mon, Jul 9, 2012 at 4:22 PM, Arnd Hannemann wrote: >> Hi, >> >> using btrfs with LVM snapshots seems to be confusing /proc/mounts >> After mounting a snapshot of an original filesystem, the devicename of the >> original filesystem is overwritten with that of the snapshot in /proc/mounts. > > If the lvm snapshot is visible to btrfs (i.e., btrfs dev scan), it > will appear as another device which belongs to the original filesystem > with a duplicate devid. This might result in bad things happening, or > possibly just hilarity. You are right the same bug seems to get triggered on "btrfs dev scan": arnd@kallisto:/mnt$ sudo grep /mnt /proc/mounts /dev/mapper/vg0-original /mnt/original btrfs rw,relatime,ssd,space_cache 0 0 arnd@kallisto:/mnt$ sudo btrfs dev scan Scanning for Btrfs filesystems failed to read /dev/sr0 ERROR: unable to scan the device '/dev/dm-4' - Device or resource busy ERROR: unable to scan the device '/dev/dm-17' - Device or resource busy arnd@kallisto:/mnt$ sudo grep /mnt /proc/mounts /dev/dm-16 /mnt/original btrfs rw,relatime,ssd,space_cache 0 0 arnd@kallisto:/mnt$ sudo dmsetup info /dev/dm-16 Name: vg0-testsnap State: ACTIVE Read Ahead:256 Tables present:LIVE Open count:0 Event number: 0 Major, minor: 253, 16 Number of targets: 1 UUID: LVM-pUa0TTDg9Y1dII6a6WwcUanE0ai4AVXqpS7sNnWEGZOnww76lrMaZzIEB38rug9 > You have a backup that isn't just an lvm snapshot, right? Now I will. Best regards Arnd -- 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: 3.5.0-rc6: btrfs and LVM snapshots -> wrong devicename in /proc/mounts
Hi, Am 10.07.2012 05:30, schrieb Christian Robert: > I agree with you, but you should never mount a snapshot of a btrfs filesystem > at the same time the original is, > because both the original and the snapshot had same "device fsid > 5c3e8ca2-da56-4ade-9fef-103a6a8a70c2" > > the kernel will tkink twice and fold back to the same device. If that is correct the bug is that the kernel lets me mount the same device fsid on different devices twice. > > btrsf does not behave like other filesystems, you can't snapshot a btrfs > filesystem > and hope to mount the snapshot somewhere else. > snapsoot also duplicate lots of things internally that have no sence in a > snapshot (like raid level, single or multiple devies ...) I see. However, I expect a "simple" btrfs to just work or fail gracefully. Best regards, Arnd -- 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
3.5.0-rc6: btrfs and LVM snapshots -> wrong devicename in /proc/mounts
Hi, using btrfs with LVM snapshots seems to be confusing /proc/mounts After mounting a snapshot of an original filesystem, the devicename of the original filesystem is overwritten with that of the snapshot in /proc/mounts. Steps to reproduce: arnd@kallisto:/mnt$ sudo mount /dev/vg0/original /mnt/original [ 107.041432] device fsid 5c3e8ca2-da56-4ade-9fef-103a6a8a70c2 devid 1 transid 4 /dev/mapper/vg0-original [ 107.044691] btrfs: no dev_stats entry found for device /dev/mapper/vg0-original (devid 1) (OK on first mount after mkfs) arnd@kallisto:/mnt$ cat /proc/mounts | grep /mnt /dev/mapper/vg0-original /mnt/original btrfs rw,relatime,ssd,space_cache 0 0 arnd@kallisto:/mnt$ sudo lvcreate -L 10M --snap --name snapshot /dev/vg0/original arnd@kallisto:/mnt$ sudo mount /dev/vg0/testsnap /mnt/testsnap [ 215.432281] device fsid 5c3e8ca2-da56-4ade-9fef-103a6a8a70c2 devid 1 transid 4 /dev/mapper/vg0-testsnap arnd@kallisto:/mnt$ cat /proc/mounts | grep /mnt /dev/mapper/vg0-testsnap /mnt/original btrfs rw,relatime,ssd,space_cache 0 0 /dev/mapper/vg0-testsnap /mnt/testsnap btrfs rw,relatime,ssd,space_cache 0 0 arnd@kallisto:/mnt$ sudo umount /dev/vg0/testsnap arnd@kallisto:/mnt$ cat /proc/mounts | grep /mnt /dev/mapper/vg0-testsnap /mnt/original btrfs rw,relatime,ssd,space_cache 0 0 Best regards, Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] btrfs-progs: btrfs-image: don't segfault if no root is found
Error reporting is already done, so just return if root is NULL, instead of segfaulting: Program received signal SIGSEGV, Segmentation fault. 0x0042cd34 in create_metadump (input=0x7fffe847 "/usr/share", out=0x63e010, num_threads=0, compress_level=0) at btrfs-image.c:494 494 BUG_ON(root->nodesize != root->leafsize); at btrfs-image.c:494 Signed-off-by: Arnd Hannemann --- btrfs-image.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/btrfs-image.c b/btrfs-image.c index f2bbcc8..fec51d8 100644 --- a/btrfs-image.c +++ b/btrfs-image.c @@ -491,6 +491,8 @@ static int create_metadump(const char *input, FILE *out, int num_threads, int ret; root = open_ctree(input, 0, 0); + if (!root) + return 1; BUG_ON(root->nodesize != root->leafsize); ret = metadump_init(&metadump, root, out, num_threads, -- 1.7.9.5 -- 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 v2] Btrfs: allow mount -o remount,compress=no
Hi Chris, Am 16.04.2012 16:42, schrieb David Sterba: > On Mon, Apr 16, 2012 at 03:27:51PM +0200, Arnd Hannemann wrote: >> Btrfs allows to turn on compression on a mounted and used filesystem >> by issuing mount -o remount,compress=lzo. >> This patch allows to turn compression off again >> while the filesystem is mounted. As suggested by David Sterba >> if the compress-force option was set, it is implicitly cleared >> if compression is turned off. >> >> Signed-off-by: Arnd Hannemann > > Tested-by: David Sterba > > worked perfectly, remounting back and forth with compress=lzo =no > -force=lzo etc, checked output via 'mount'. How show should we proceed to get above mentioned patch (or the similar patch from Andrei Popa) merged? Best regards, Arnd -- 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
3.5.0-rc4: WARNING: at fs/btrfs/super.c:221 __btrfs_abort_transaction+0xae/0xc0 (was: Re: 3.4.0-rc6:...)
Hi, still seeing this warning (well the line number changed) on 3.5.0 (rc4): [ 11.909589] [ cut here ] [ 11.909616] WARNING: at /home/arnd/Projekte/kernel/linux-2.6/fs/btrfs/super.c:221 __btrfs_abort_transaction+0xae/0xc0 [btrfs]() [ 11.909617] Hardware name: 4384GEG [ 11.909619] btrfs: Transaction aborted [ 11.909648] Modules linked in: joydev deflate ctr bridge stp llc twofish_generic twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_x86_64 serpent_sse2_x86_64 lrw serpent_generic xts gf128mul blowfish_generic blowfish_x86_64 blowfish_common cast5 des_generic xcbc rmd160 sha512_generic crypto_null af_key xfrm_algo dm_crypt bnep rfcomm bluetooth binfmt_misc arc4 snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm coretemp kvm_intel kvm snd_seq_midi snd_rawmidi thinkpad_acpi microcode snd_seq_midi_event qcserial usb_wwan usbserial snd_seq snd_timer psmouse snd_seq_device serio_raw intel_ips snd iwlwifi tpm_tis nvram lpc_ich soundcore mac80211 snd_page_alloc cfg80211 mei btrfs zlib_deflate libcrc32c mxm_wmi ghash_clmulni_intel aesni_intel cryptd aes_x86_64 i915 e1000e ahci libahci drm_kms_helper drm firewire_ohci i2c_algo_bit video firewire_core crc_itu_t wmi sdhci_pci sdhci [ 11.909651] Pid: 1509, comm: hybrid-detect Not tainted 3.5.0-rc4aha+ #6 [ 11.909652] Call Trace: [ 11.909659] [] warn_slowpath_common+0x7f/0xc0 [ 11.909661] [] warn_slowpath_fmt+0x46/0x50 [ 11.909669] [] ? do_chunk_alloc.isra.71+0x311/0x3f0 [btrfs] [ 11.909676] [] __btrfs_abort_transaction+0xae/0xc0 [btrfs] [ 11.909683] [] find_free_extent+0xbe5/0xc70 [btrfs] [ 11.909688] [] ? __free_pages+0x2d/0x40 [ 11.909696] [] btrfs_reserve_extent+0xed/0x250 [btrfs] [ 11.909705] [] btrfs_alloc_free_block+0x177/0x380 [btrfs] [ 11.909712] [] __btrfs_cow_block+0x124/0x500 [btrfs] [ 11.909719] [] btrfs_cow_block+0xfc/0x220 [btrfs] [ 11.909726] [] btrfs_search_slot+0x454/0x910 [btrfs] [ 11.909733] [] ? reserve_metadata_bytes.isra.72+0x207/0x740 [btrfs] [ 11.909741] [] btrfs_insert_empty_items+0x7c/0xe0 [btrfs] [ 11.909747] [] ? btrfs_alloc_path+0x1a/0x20 [btrfs] [ 11.909758] [] btrfs_insert_orphan_item+0x5f/0x90 [btrfs] [ 11.909768] [] btrfs_orphan_add+0xbb/0x180 [btrfs] [ 11.909778] [] btrfs_truncate+0x140/0x650 [btrfs] [ 11.909782] [] ? mutex_lock+0x1d/0x50 [ 11.909793] [] btrfs_setattr+0xbb/0x1d0 [btrfs] [ 11.909797] [] notify_change+0x1c3/0x350 [ 11.909801] [] do_truncate+0x5e/0xa0 [ 11.909805] [] do_last+0x4cd/0x9e0 [ 11.909808] [] path_openat+0xd6/0x440 [ 11.909811] [] do_filp_open+0x42/0xa0 [ 11.909814] [] ? alloc_fd+0xd1/0x120 [ 11.909816] [] do_sys_open+0xf8/0x1d0 [ 11.909819] [] ? filp_close+0x66/0x90 [ 11.909820] [] sys_open+0x21/0x30 [ 11.909824] [] system_call_fastpath+0x16/0x1b [ 11.909825] ---[ end trace 247ff970a7eff763 ]--- [ 11.909827] BTRFS warning (device dm-4): Aborting unused transaction. Best regards Arnd -- 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: 3.4.0-rc6: WARNING: at fs/btrfs/super.c:219 __btrfs_abort_transaction+0xae/0xc0 [btrfs]()
Hi, I just got the same warning on a fresh 3.4.0 final while booting. This time on /usr/share (different filesystem from last time): arnd@kallisto:~$ ls -l /dev/mapper/vg0-usr_share lrwxrwxrwx 1 root root 7 Mai 22 17:59 /dev/mapper/vg0-usr_share -> ../dm-4 arnd@kallisto:~$ grep usr_share /proc/mounts /dev/mapper/vg0-usr_share /usr/share btrfs rw,relatime,compress=zlib,ssd,nospace_cache 0 0 [ 12.326239] [ cut here ] [ 12.326264] WARNING: at /home/arnd/Projekte/kernel/linux-2.6/fs/btrfs/super.c:219 __btrfs_abort_transaction+0xae/0xc0 [btrfs]() [ 12.326266] Hardware name: 4384GEG [ 12.326267] btrfs: Transaction aborted [ 12.326268] Modules linked in: joydev bridge stp llc kvm_intel kvm dm_crypt bnep rfcomm bluetooth binfmt_misc arc4 coretemp snd_hda_codec_hdmi snd_hda_codec_conexant thinkpad_acpi microcode snd_seq_midi psmouse snd_rawmidi serio_raw iwlwifi intel_ips qcserial usb_wwan usbserial mac80211 snd_hda_intel snd_seq_midi_event snd_hda_codec snd_seq snd_hwdep cfg80211 snd_seq_device snd_pcm snd_timer snd_page_alloc snd soundcore tpm_tis nvram mei(C) btrfs zlib_deflate libcrc32c mxm_wmi ghash_clmulni_intel aesni_intel cryptd aes_x86_64 i915 ahci libahci drm_kms_helper drm e1000e sdhci_pci sdhci firewire_ohci firewire_core i2c_algo_bit crc_itu_t video wmi [ 12.326297] Pid: 1471, comm: hybrid-detect Tainted: G C 3.4.0aha+ #11 [ 12.326298] Call Trace: [ 12.326305] [] warn_slowpath_common+0x7f/0xc0 [ 12.326307] [] warn_slowpath_fmt+0x46/0x50 [ 12.326315] [] ? do_chunk_alloc.isra.71+0x31c/0x3f0 [btrfs] [ 12.326322] [] __btrfs_abort_transaction+0xae/0xc0 [btrfs] [ 12.326329] [] find_free_extent+0xbe5/0xc70 [btrfs] [ 12.326334] [] ? __switch_to+0x17a/0x410 [ 12.326341] [] btrfs_reserve_extent+0xed/0x250 [btrfs] [ 12.326350] [] btrfs_alloc_free_block+0x177/0x370 [btrfs] [ 12.326357] [] __btrfs_cow_block+0x135/0x4d0 [btrfs] [ 12.326363] [] btrfs_cow_block+0xfc/0x220 [btrfs] [ 12.326370] [] btrfs_search_slot+0x454/0x910 [btrfs] [ 12.326377] [] ? reserve_metadata_bytes.isra.72+0x207/0x740 [btrfs] [ 12.326384] [] btrfs_insert_empty_items+0x7c/0xe0 [btrfs] [ 12.326390] [] ? btrfs_alloc_path+0x1a/0x20 [btrfs] [ 12.326401] [] btrfs_insert_orphan_item+0x5f/0x90 [btrfs] [ 12.326429] [] btrfs_orphan_add+0xc5/0x1c0 [btrfs] [ 12.326443] [] btrfs_truncate+0x146/0x650 [btrfs] [ 12.326449] [] ? security_inode_alloc+0x1e/0x20 [ 12.326461] [] btrfs_setattr+0xc1/0x1b0 [btrfs] [ 12.326464] [] notify_change+0x1aa/0x340 [ 12.326467] [] do_truncate+0x5e/0xa0 [ 12.326470] [] do_last+0x581/0x8f0 [ 12.326472] [] path_openat+0xd2/0x400 [ 12.326474] [] do_filp_open+0x42/0xa0 [ 12.326476] [] ? alloc_fd+0xd1/0x120 [ 12.326478] [] do_sys_open+0xf8/0x1d0 [ 12.326480] [] ? filp_close+0x66/0x90 [ 12.326482] [] sys_open+0x21/0x30 [ 12.326485] [] system_call_fastpath+0x16/0x1b [ 12.326487] ---[ end trace 4479826ac6de5588 ]--- [ 12.326489] BTRFS warning (device dm-4): Aborting unused transaction. Best regards Arnd -- 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: 3.4.0-rc6: WARNING: at fs/btrfs/super.c:219 __btrfs_abort_transaction+0xae/0xc0 [btrfs]()
Hello David, Am 14.05.2012 17:05, schrieb David Sterba: > On Mon, May 14, 2012 at 03:18:46PM +0200, Arnd Hannemann wrote: >> I just got the following warning on a compressed btrfs filesystem, while >> writing on it >> until no remaining space was available. >> Looks like a bit verbose "disk full" message, is it expected behavior? > > Shouldn't be the case for regular ENOSPC (ie. when the space is reserved > in advance and with the possibility to fail early). If the transaction > is aborted, it means it's too late and there was some logic error. > > Can you please describe more the fs and how did you fill it? Like single > process or multiple, dd or whatever. the particular filesystem is used for chroots (/opt/chroots). It got full while installing texlive-extra on a debian squeeze (i386) chroot. It was probably a single process, but it involed a lot of small files. Best regards Arnd -- 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
3.4.0-rc6: WARNING: at fs/btrfs/super.c:219 __btrfs_abort_transaction+0xae/0xc0 [btrfs]()
Hi, I just got the following warning on a compressed btrfs filesystem, while writing on it until no remaining space was available. Looks like a bit verbose "disk full" message, is it expected behavior? [22403.015529] [ cut here ] [22403.015572] WARNING: at /home/arnd/Projekte/kernel/linux-2.6/fs/btrfs/super.c:219 __btrfs_abort_transaction+0xae/0xc0 [btrfs]() [22403.015577] Hardware name: 4384GEG [22403.015579] btrfs: Transaction aborted [22403.015581] Modules linked in: dm_crypt ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables joydev bridge stp llc kvm_intel kvm bnep rfcomm bluetooth binfmt_misc arc4 snd_hda_codec_hdmi snd_hda_codec_conexant coretemp snd_hda_intel thinkpad_acpi microcode snd_hda_codec snd_hwdep snd_pcm qcserial usb_wwan psmouse usbserial snd_seq_midi serio_raw snd_rawmidi iwlwifi snd_seq_midi_event snd_seq intel_ips mac80211 snd_timer snd_seq_device cfg80211 snd snd_page_alloc mei(C) soundcore tpm_tis nvram btrfs zlib_deflate libcrc32c mxm_wmi ghash_clmulni_intel aesni_intel cryptd aes_x86_64 i915 drm_kms_helper sdhci_pci sdhci drm firewire_ohci i2c_algo_bit firewire_core crc_itu_t ahci libahci wmi video e1000e [22403.015668] Pid: 24802, comm: btrfs-delalloc- Tainted: G C 3.4.0-rc6aha+ #8 [22403.015671] Call Trace: [22403.015683] [] warn_slowpath_common+0x7f/0xc0 [22403.015689] [] warn_slowpath_fmt+0x46/0x50 [22403.015711] [] ? btrfs_reserve_extent+0xed/0x250 [btrfs] [22403.015728] [] __btrfs_abort_transaction+0xae/0xc0 [btrfs] [22403.015754] [] submit_compressed_extents+0x212/0x480 [btrfs] [22403.015781] [] async_cow_submit+0x84/0x90 [btrfs] [22403.015807] [] run_ordered_completions+0x78/0xf0 [btrfs] [22403.015833] [] worker_loop+0x185/0x5d0 [btrfs] [22403.015840] [] ? __wake_up_common+0x58/0x90 [22403.015867] [] ? btrfs_queue_worker+0x310/0x310 [btrfs] [22403.015873] [] kthread+0x93/0xa0 [22403.015880] [] kernel_thread_helper+0x4/0x10 [22403.015886] [] ? kthread_freezable_should_stop+0x70/0x70 [22403.015891] [] ? gs_change+0x13/0x13 [22403.015895] ---[ end trace 768f569fb0306239 ]--- [22403.015898] BTRFS warning (device dm-6): Aborting unused transaction. [22403.064892] BTRFS warning (device dm-6): Aborting unused transaction. [22403.094675] BTRFS warning (device dm-6): Aborting unused transaction. [22403.512902] BTRFS warning (device dm-6): Aborting unused transaction. [22403.703871] BTRFS warning (device dm-6): Aborting unused transaction. [22403.709637] BTRFS warning (device dm-6): Aborting unused transaction. [22403.721362] BTRFS warning (device dm-6): Aborting unused transaction. [22403.736999] BTRFS warning (device dm-6): Aborting unused transaction. [22403.794067] BTRFS warning (device dm-6): Aborting unused transaction. [22403.799009] BTRFS warning (device dm-6): Aborting unused transaction. [22404.035483] BTRFS warning (device dm-6): Aborting unused transaction. [22404.108751] BTRFS warning (device dm-6): Aborting unused transaction. Best regards Arnd -- 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 v2] Btrfs: allow mount -o remount,compress=no
Btrfs allows to turn on compression on a mounted and used filesystem
by issuing mount -o remount,compress=lzo.
This patch allows to turn compression off again
while the filesystem is mounted. As suggested by David Sterba
if the compress-force option was set, it is implicitly cleared
if compression is turned off.
Signed-off-by: Arnd Hannemann
---
fs/btrfs/super.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 8d5d380..79a2ca5 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -394,15 +394,22 @@ int btrfs_parse_options(struct btrfs_root *root, char
*options)
strcmp(args[0].from, "zlib") == 0) {
compress_type = "zlib";
info->compress_type = BTRFS_COMPRESS_ZLIB;
+ btrfs_set_opt(info->mount_opt, COMPRESS);
} else if (strcmp(args[0].from, "lzo") == 0) {
compress_type = "lzo";
info->compress_type = BTRFS_COMPRESS_LZO;
+ btrfs_set_opt(info->mount_opt, COMPRESS);
+ } else if (strncmp(args[0].from, "no", 2) == 0) {
+ compress_type = "no";
+ info->compress_type = BTRFS_COMPRESS_NONE;
+ btrfs_clear_opt(info->mount_opt, COMPRESS);
+ btrfs_clear_opt(info->mount_opt,
FORCE_COMPRESS);
+ compress_force = false;
} else {
ret = -EINVAL;
goto out;
}
- btrfs_set_opt(info->mount_opt, COMPRESS);
if (compress_force) {
btrfs_set_opt(info->mount_opt, FORCE_COMPRESS);
pr_info("btrfs: force %s compression\n",
--
1.7.9.5
--
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: hard links
Hi Hugo, Am 04.04.2012 21:53, schrieb Hugo Mills: > On Wed, Apr 04, 2012 at 09:39:39PM +0200, Arnd Hannemann wrote: >> Am 04.04.2012 21:33, schrieb Shyam Prasad N: >>> On 04/04/2012 10:08 PM, Arnd Hannemann wrote: >>>> Hi, >>>> >>>> today I experimented with hard links on btrfs and by this used all >>>> available inode space of a file. >>>> Interestingly if this happens even a rename of such an filename to an >>>> _equal length_ filename >>>> fails: >>>> >>>> arnd@kallisto:/mnt/btrfs/tmp$ mv a b >>>> mv: cannot move `a' to `b': Too many links >>>> >>>> Is this expected behavior? >>>> There should be no reason to let this particular case fail? >>>> >> >>> What do you mean by 'used all available inode space'? What did you do >>> exactly? >> > >There's no inode limit specifically. The limit is on the number of > hardlinks to the same file stored in the same directory (and it's very > small). This is a known limitation of btrfs. Someone's working on a > fix (can't remember who, off-hand), but it's not been published yet. Sorry maybe I was unclear. I didn't want to say I used up all inodes. I wanted to express that I filled up the space of a particular inode. My understanding is that the limit on the number of hardlinks to the same file stored in the same directory, is, because the names of the hardlinks are stored within the same inode. As such the number of hardlinks is naturally limited by the size of the inode (and dependent on the length of the filenames). Correct? It's not a big deal, but with my original posting I just tried to point out that btrfs fails an operation while the above constraint is not violated. The size needed to store the filename "a" is exactly the same as the size needed to store the filename "b". Therefore, I would assume the operation mv "a" "b" to just work. I hope I did clarify my point? Best regards Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Btrfs: allow mount -o remount,compress=no
Btrfs allows to turn on compression on a mounted and used filesystem
by issuing mount -o remount,compress=lzo.
This patch allows to turn compression off again
while the filesystem is mounted.
Signed-off-by: Arnd Hannemann
---
fs/btrfs/super.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 8d5d380..f1fb6c0 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -394,15 +394,20 @@ int btrfs_parse_options(struct btrfs_root *root, char
*options)
strcmp(args[0].from, "zlib") == 0) {
compress_type = "zlib";
info->compress_type = BTRFS_COMPRESS_ZLIB;
+ btrfs_set_opt(info->mount_opt, COMPRESS);
} else if (strcmp(args[0].from, "lzo") == 0) {
compress_type = "lzo";
info->compress_type = BTRFS_COMPRESS_LZO;
+ btrfs_set_opt(info->mount_opt, COMPRESS);
+ } else if (strncmp(args[0].from, "no", 2) == 0) {
+ compress_type = "no";
+ info->compress_type = BTRFS_COMPRESS_NONE;
+ btrfs_clear_opt(info->mount_opt, COMPRESS);
} else {
ret = -EINVAL;
goto out;
}
- btrfs_set_opt(info->mount_opt, COMPRESS);
if (compress_force) {
btrfs_set_opt(info->mount_opt, FORCE_COMPRESS);
pr_info("btrfs: force %s compression\n",
--
1.7.9.1
--
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: hard links
Hi Shyam,
Am 04.04.2012 21:33, schrieb Shyam Prasad N:
> On 04/04/2012 10:08 PM, Arnd Hannemann wrote:
>> Hi,
>>
>> today I experimented with hard links on btrfs and by this used all available
>> inode space of a file.
>> Interestingly if this happens even a rename of such an filename to an
>> _equal length_ filename
>> fails:
>>
>> arnd@kallisto:/mnt/btrfs/tmp$ mv a b
>> mv: cannot move `a' to `b': Too many links
>>
>> Is this expected behavior?
>> There should be no reason to let this particular case fail?
>>
> What do you mean by 'used all available inode space'? What did you do exactly?
I created hard links of a file in the same directory until no additional one
can be created.
Eg.:
touch a
for i in {1..1000}; do ln a $i; done;
Best regards
Arnd
--
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
hard links
Hi, today I experimented with hard links on btrfs and by this used all available inode space of a file. Interestingly if this happens even a rename of such an filename to an _equal length_ filename fails: arnd@kallisto:/mnt/btrfs/tmp$ mv a b mv: cannot move `a' to `b': Too many links Is this expected behavior? There should be no reason to let this particular case fail? Best regards, Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Btrfs-progs: Fix some typos in btrfs man page
This Patch fixes some minor typos in the btrfs man page. Signed-off-by: Arnd Hannemann --- man/btrfs.8.in |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/man/btrfs.8.in b/man/btrfs.8.in index be478e0..bafca8d 100644 --- a/man/btrfs.8.in +++ b/man/btrfs.8.in @@ -137,7 +137,7 @@ is similar to \fBsubvolume list\fR command. Defragment file data and/or directory metadata. To defragment all files in a directory you have to specify each one on its own or use your shell wildcards. -The start position and the number of bytes to deframention can be specified by \fIstart\fR and \fIlen\fR. Any extent bigger than \fIthresh\fR will be considered already defragged. Use 0 to take the kernel default, and use 1 to say eveery single extent must be rewritten. You can also turn on compression in defragment operations. +The start position and the number of bytes to defragmention can be specified by \fIstart\fR and \fIlen\fR. Any extent bigger than \fIthresh\fR will be considered already defragged. Use 0 to take the kernel default, and use 1 to say every single extent must be rewritten. You can also turn on compression in defragment operations. \fB-v\fP be verbose @@ -291,7 +291,7 @@ Resolves an in subvolume to all filesystem paths. \fIOptions\fR .IP -v 5 -verbose mode. print count of returned paths and ioctl() return value +verbose mode. Print count of returned paths and ioctl() return value. .RE .TP @@ -305,11 +305,11 @@ By default, each inode is then resolved to a file system path (similar to the .IP -P 5 skip the path resolving and print the inodes instead .IP -v 5 -verbose mode. print count of returned paths and all ioctl() return values +verbose mode. Print count of returned paths and all ioctl() return values. .RE .SH EXIT STATUS -\fBbtrfs\fR returns a zero exist status if it succeeds. Non zero is returned in +\fBbtrfs\fR returns a zero exit status if it succeeds. Non zero is returned in case of failure. .SH AVAILABILITY -- 1.7.5.4 -- 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: compressed btrfs "No space left on device"
Am 14.11.2011 19:24, schrieb Arnd Hannemann: > Am 14.11.2011 15:57, schrieb Arnd Hannemann: > >> I'm using btrfs for my /usr/share/ partition and keep getting the following >> error >> while installing a debian package which should take no more than 228 MB: >> >> Unpacking texlive-fonts-extra (from >> .../texlive-fonts-extra_2009-10ubuntu1_all.deb) ... >> dpkg: error processing >> /var/cache/apt/archives/texlive-fonts-extra_2009-10ubuntu1_all.deb >> (--unpack): >> unable to install new version of >> `/usr/share/texmf-texlive/fonts/type1/public/allrunes/frutlt.pfb': No space >> left on device >> >> >> However df reports plenty of available space: >> >> /dev/mapper/vg0-usr_share >> 5.0G 1.5G 2.5G 37% /usr/share >> >> >> I already extended /dev/mapper/vg0-usr_share from 4G to 5G and ran defrag >> and balance on it with no luck. >> I'm using ubuntu 11.10 on amd64 with the ubuntu 3.0.0 kernel. > > FYI: The problem is the same with mainline kernel v3.1.1. JFYI: the problem went away in 3.2-rc2 so someone must have fixed something. Thanks! Best regards Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Btrfs: Prefix resize related printks with btrfs:
For the user it is confusing to find something like:
[10197.627710] new size for /dev/mapper/vg0-usr_share is 3221225472
in kernel log, because it doesn't point directly to btrfs.
This patch prefixes those messages with "btrfs:" like other btrfs
related printks.
Signed-off-by: Arnd Hannemann
---
fs/btrfs/ioctl.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 4a34c47..b6d2a1a 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1216,12 +1216,12 @@ static noinline int btrfs_ioctl_resize(struct
btrfs_root *root,
*devstr = '\0';
devstr = vol_args->name;
devid = simple_strtoull(devstr, &end, 10);
- printk(KERN_INFO "resizing devid %llu\n",
+ printk(KERN_INFO "btrfs: resizing devid %llu\n",
(unsigned long long)devid);
}
device = btrfs_find_device(root, devid, NULL, NULL);
if (!device) {
- printk(KERN_INFO "resizer unable to find device %llu\n",
+ printk(KERN_INFO "btrfs: resizer unable to find device %llu\n",
(unsigned long long)devid);
ret = -EINVAL;
goto out_unlock;
@@ -1267,7 +1267,7 @@ static noinline int btrfs_ioctl_resize(struct btrfs_root
*root,
do_div(new_size, root->sectorsize);
new_size *= root->sectorsize;
- printk(KERN_INFO "new size for %s is %llu\n",
+ printk(KERN_INFO "btrfs: new size for %s is %llu\n",
device->name, (unsigned long long)new_size);
if (new_size > old_size) {
--
1.7.5.4
--
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] Fix URL of btrfs-progs git repository in docs
The location of the btrfs-progs repository has been changed. This patch updates the documentation accordingly. Signed-off-by: Arnd Hannemann --- Documentation/filesystems/btrfs.txt |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index 64087c3..7671352 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -63,8 +63,8 @@ IRC network. Userspace tools for creating and manipulating Btrfs file systems are available from the git repository at the following location: - http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs-unstable.git - git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git + http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git + git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git These include the following tools: -- 1.7.5.4 -- 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: compressed btrfs "No space left on device"
Am 14.11.2011 15:57, schrieb Arnd Hannemann: > I'm using btrfs for my /usr/share/ partition and keep getting the following > error > while installing a debian package which should take no more than 228 MB: > > Unpacking texlive-fonts-extra (from > .../texlive-fonts-extra_2009-10ubuntu1_all.deb) ... > dpkg: error processing > /var/cache/apt/archives/texlive-fonts-extra_2009-10ubuntu1_all.deb (--unpack): > unable to install new version of > `/usr/share/texmf-texlive/fonts/type1/public/allrunes/frutlt.pfb': No space > left on device > > > However df reports plenty of available space: > > /dev/mapper/vg0-usr_share > 5.0G 1.5G 2.5G 37% /usr/share > > > I already extended /dev/mapper/vg0-usr_share from 4G to 5G and ran defrag and > balance on it with no luck. > I'm using ubuntu 11.10 on amd64 with the ubuntu 3.0.0 kernel. FYI: The problem is the same with mainline kernel v3.1.1. Best regards Arnd -- 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] Btrfs-progs: satisfy compiler and change printf modifier
Am 14.11.2011 16:30, schrieb Christian Parpart:
> On Mon, Nov 14, 2011 at 4:24 PM, Arnd Hannemann <mailto:a...@arndnet.de>> wrote:
>
> One-liner which fixes the gcc warning:
> warning: format '%u' expects argument of type 'unsigned int',
> but argument 3 has type 'long unsigned int' [-Wformat]
>
>
> [snip]
>
> - printf("Size is %u, needs to be %u, slot %d\n", item_size,
> + printf("Size is %u, needs to be %zu, slot %d\n",
> item_size,
> sizeof(*ei), path->slots[0]);
>
>
> shouldn't it be %lu then (instead of %zu) ?
No, the return type of sizeof() is size_t which is of different size on
different
architectures (eg. amd64 versus i386)
If %lu would be used, there would be a warning when compiled on an architecture
where
long is 32 bit.
Best regards,
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Btrfs-progs: Relocate -lpthread in makefile
This patch fixes the following compile error when compiled with gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3): gcc -lpthread -g -O0 -o btrfs btrfs.o btrfs_cmds.o scrub.o \ ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o btrfslabel.o -luuid scrub.o: In function `scrub_start': /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1342: undefined reference to `pthread_create' /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1360: undefined reference to `pthread_create' /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1374: undefined reference to `pthread_join' /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1430: undefined reference to `pthread_cancel' /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1432: undefined reference to `pthread_join' collect2: ld returned 1 exit status make: *** [btrfs] Error 1 The gcc man page says: "[...] the placement of the -l option is significant." so lets include -lpthread together with the usual $(LIBS) Signed-off-by: Arnd Hannemann --- Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 96e2002..834be47 100644 --- a/Makefile +++ b/Makefile @@ -37,8 +37,8 @@ version: bash version.sh btrfs: $(objects) btrfs.o btrfs_cmds.o scrub.o - $(CC) -lpthread $(CFLAGS) -o btrfs btrfs.o btrfs_cmds.o scrub.o \ - $(objects) $(LDFLAGS) $(LIBS) + $(CC) $(CFLAGS) -o btrfs btrfs.o btrfs_cmds.o scrub.o \ + $(objects) $(LDFLAGS) $(LIBS) -lpthread calc-size: $(objects) calc-size.o gcc $(CFLAGS) -o calc-size calc-size.o $(objects) $(LDFLAGS) $(LIBS) -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Btrfs-progs: satisfy compiler and change printf modifier
One-liner which fixes the gcc warning:
warning: format '%u' expects argument of type 'unsigned int',
but argument 3 has type 'long unsigned int' [-Wformat]
Signed-off-by: Arnd Hannemann
---
extent-tree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/extent-tree.c b/extent-tree.c
index 5bed3c2..5211bee 100644
--- a/extent-tree.c
+++ b/extent-tree.c
@@ -1067,7 +1067,7 @@ static int lookup_inline_extent_backref(struct
btrfs_trans_handle *trans,
}
#endif
if (item_size < sizeof(*ei)) {
- printf("Size is %u, needs to be %u, slot %d\n", item_size,
+ printf("Size is %u, needs to be %zu, slot %d\n", item_size,
sizeof(*ei), path->slots[0]);
btrfs_print_leaf(root, leaf);
return -EINVAL;
--
1.7.5.4
--
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
compressed btrfs "No space left on device"
Hi, I'm using btrfs for my /usr/share/ partition and keep getting the following error while installing a debian package which should take no more than 228 MB: Unpacking texlive-fonts-extra (from .../texlive-fonts-extra_2009-10ubuntu1_all.deb) ... dpkg: error processing /var/cache/apt/archives/texlive-fonts-extra_2009-10ubuntu1_all.deb (--unpack): unable to install new version of `/usr/share/texmf-texlive/fonts/type1/public/allrunes/frutlt.pfb': No space left on device However df reports plenty of available space: /dev/mapper/vg0-usr_share 5.0G 1.5G 2.5G 37% /usr/share I already extended /dev/mapper/vg0-usr_share from 4G to 5G and ran defrag and balance on it with no luck. I'm using ubuntu 11.10 on amd64 with the ubuntu 3.0.0 kernel. btrfs reports to use "zlib compression". Is this a known problem with compressed btrfs? Best regards Arnd -- 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
