Re: Massive filesystem corruption since kernel 5.2 (ARCH)

Le 12/09/2019 à 18:21, Zdenek Kaspar a écrit : On 9/12/19 4:57 PM, Swâmi Petaramesh wrote: However having read that the bug is diagnosed, confirmed and fixed by Filipe, I seriously consider downgrading my kernel back to 5.1 on the 2 Manjaro machines as it is rather straightforward, and maybe

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

e FS on which I store all of my most precious data and considered “the safest native Linux FS available” can still suffer such regressions that can plainly trash it to ruins. Kind regards. > ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

actually did so for two of mine... ॐ -- Swâmi Petaramesh OpenPGP ID 0x1BFFD850

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

Hi Filipe, On 9/12/19 9:50 AM, Filipe Manana wrote: > So we definitely have a serious regression introduced on 5.2. > I sent out a fix for it yesterday: > https://patchwork.kernel.org/patch/11141559/ Many thanks for having found and patched it. Kind regards. ॐ -- Swâmi Petara

Re: Cloning / getting a full backup of a BTRFS filesystem

the tool I was looking for. Thannk you all for your input. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Cloning / getting a full backup of a BTRFS filesystem

a single operation. If the answer is « There's no way it can be done » then it is really badly annoying... ॐ -- Swâmi Petaramesh PGP 9076E32E

Cloning / getting a full backup of a BTRFS filesystem

not do the job as they usually lack behind recent BTRFS features, and may not be able to clone BTRFS RAID setups for example...) TIA. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

definitely some bug out there. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

Hi Alberto, Le 27/08/2019 à 13:11, Alberto Bursi a écrit : > If you want to fully clear cache you need to use (on an unmounted > filesystem) > > btrfs check --clear-space-cache v1 /dev/sdX It worked, thanks. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

Le 27/08/2019 à 13:29, Alberto Bursi a écrit : > hpprobook:/home/alby # btrfs check --clear-space-cache v1 /dev/sdd1 My mistake, I read it too fast and tried it a a mount option... ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

Le 27/08/2019 à 13:11, Alberto Bursi a écrit : > > > btrfs check --clear-space-cache v1 /dev/sdX “Bad option” (even with _ instead of - and between option and v1 or V2... ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

2832 total fs tree bytes: 1992900608 total extent tree bytes: 101548032 btree space waste bytes: 380804019 file data blocks allocated: 626135306240 referenced 124464697344 root@PartedMagic:~# So it seems that mounting with “clear_cache” did not actually clear the cache and fix the issue ? ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

e. > So you can't really escape from free space cache. I meant that I had understood that the V2 space cache was preferable to V1 only for multi-TB filesystems. So would you advise to use V2 space cache also for filesystems < 1 TB ? TIA. Kind regards. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

#x27;m back. Should I understand your statement as an advice to clear the space cache even though the kernel said it has rebuilt it, or to use the V2 space cache generally speaking, on any machine that I use (I had understood it was useful only on multi-TB filesystems...) Thanks. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

Le 27/08/2019 à 07:06, Swâmi Petaramesh a écrit : > > Now the machine looks stable so far with a 5.2, albeit more recent, Arch > kernel : 5.2.9-arch1-1-ARCH. As my 1st machine looks fairly stable now, I just upgraded to 5.2 another one that had always been running <= 5.1 before.

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

Hi, Le 27/08/2019 à 02:00, Christoph Anton Mitterer a écrit : > > On Sun, 2019-08-25 at 12:00 +0200, Swâmi Petaramesh wrote: >> I haven't seen any filesystem issue since, but I haven't used the >> system >> very much yet. > > Hmm strange... so could it

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

ion since. Hope this helps a bit. Kind regards. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Unable to mount, even in recovery, parent transid verify failed on raid 1

; on 343428399104 wanted 18163 found 19034 > [ 1088.154921] BTRFS warning (device sdc): failed to read root (objectid=4): > -5 > [ 1088.261675] BTRFS error (device sdc): open_ctree failed > > btrfs-find-root log attached > > I do have partial backup but it is a little outdated and would really > appreciate help either fixing the filesystem, or finding out how to > recover it with as minimal loss as possible. Thank you for the help! > -- ॐ Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

#x27;ve seen that Arch has released 3-4 kernel 5.2 package updates since, so it won't be the exact same kernel by the time I test again). I will be on vacation until August, 20, so I cannot perform this test before I'm back. But I'll be glad to help if I can and thank you very much for your help with this issue. Best regards. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

Le 01/08/2019 à 15:46, Anand Jain a écrit : > Swami, Do you have the kernel logs around this time frame? No, it really got lost. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

t have useful logs available. > (It's a really pity that the original corrupted leaf kernel message > can't be preserved, that could really help a lot to detect memory > corruption or things like that Well I'm sorry.. Kind regards. -- ॐ Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

, the issue doesn't relate to the most complex setups. I am under the unproved but strong feeling that the mess has something to do with snapshots deletion with kernel 5.2... Dunno if it can be of some help. Kind regards. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

ay be very annoying and very time consuming rebuilding. Kind regards. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: [BUG] BTRFS critical corrupt leaf - bisected to 496245cac57e

Hello, Le 30/07/2019 à 09:21, Qu Wenruo a écrit : > Unfortunately, transid error here helps nothing. Now, each and everytime I try to mount this disk on the original machine, or another one, I get : systemd[1]: run-media-.mount: Succeeded. kernel: BTRFS info (device dm-2): disk s

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

ernel packages i.e. https://www.archlinux.org/packages/core/x86_64/linux/ (There's been another upgrade since the fisrt 4.2.x I installed, with reported issues...) Kind regards. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

air and having to reformat everything and restore everything... Kind regards. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: [BUG] BTRFS critical corrupt leaf - bisected to 496245cac57e

;t boot to GUI anymore but I would still be able to log in in console and see that the log was crowded with failing services and BTRFS errors. Then I reformatted and reinstalled from backup, so the corresponding logs are indeed lost. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

many different drives > and setups affected. Some of the strangest problems I have ever seen > in computing were directly attributed to noise on the power line. Yeah, but in this case, being a laptop with the main power being filtered by the battery, I wouldn't expect a power issue...

Re: [BUG] BTRFS critical corrupt leaf - bisected to 496245cac57e

block group ro: -30 BTRFS info (device dm-3): scrub: not finished on devid 1 with status: -30 Hope this helps... ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

On 7/29/19 4:55 PM, Swâmi Petaramesh wrote: > Well  All the errors I detailed today happen on the SAME FS, and this fs > is a BTRFS that was created on a new HD with a recent kernel (surely >= > 4.19) only a few months ago. > > And the errors I have one this one, As far as I can

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

hines SSD as soons as I installer a 5.2 kernel... Kind regards. -- ॐ Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

and I have deployed BTRFS on dozens of systems (OK maybe not hundreds, not sure)... Kind regards. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

to be addressed. So how could I help with this one ? TIA ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

losses of this backup disk (next backup will fix missing files) But I DO NOT want to lose (or have to recreate) the complete FS with all its subvols and snapshots, which I have no other disk to copy to currently. So I can accept a « fix with losses », but not a « well you need to reformat the

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

.2 kernel...) -- ॐ Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

Le 29/07/2019 à 15:52, Swâmi Petaramesh a écrit : > > Please tell me how I could help. Here is the complete output of BTRFS check, ressembling exactly to what I saw on the 1st disk that broke. QUESTION : If I run « btrfs check » in repair mode, is there any hope it will repair the FS pr

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

d help. This machine was extremely stable (for years) before upgrading from kernel 5.1 to 5.2 so unless the hardware is failing, I can hardly imagine what else could be the problem... Both FSes are BTRFS over LUKS (one using an LVM, the other not). Kind regards. -- ॐ Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

bite... ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

99 Ignoring transid failure Wrong key of child node/leaf, wanted: (1797454, 96, 23), have: (18446744073709551606, 128, 2538887163904) Wrong generation of child node/leaf, wanted: 7499, have: 7684 Uh I'm at a loss... ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

Arch first broke its BTRFS main FS and I told myself it was years old, so maybe some old corruption undetected by scrub so far... But the external HD that just broke is less than 6 months old and has been formatted with at least a 4.20 kernel... And is used purely for backups. So this I don&#x

Re: Massive filesystem corruption since kernel 5.2 (ARCH)

Le 29/07/2019 à 14:32, Swâmi Petaramesh a écrit : > > Today, same machine, but this time my external BTRFS (over LUKS) backup > USB HDD went corrupt the same. btrfs check reports as follows : # btrfs check /dev/mapper/luks-UUID Opening filesystem to check... Checking filesystem on /d

[BUG] BTRFS critical corrupt leaf - bisected to 496245cac57e

Hi, The corruption issue that you report just after upgrading to kernel 5.2 resembles very much to what I had on 2 filesystems after such an upgrade. I think I'me gonna emergency downgrade all my BTRFS machines to kernel 5.1 before they break ,-( ॐ -- Swâmi Petaramesh PGP 9076E32E

Massive filesystem corruption since kernel 5.2 (ARCH)

or similar numbers) So I'm under the impression that either my laptop's RAM is dying, or something is *very* broke in BTRFS in kernel 5.2. Any hint or advice very much appreciated. Kind regards. ॐ -- Swâmi Petaramesh PGP 9076E32E

Re: duperemove : some real world figures on BTRFS deduplication

t;, that says : - Timed cached reads : 5976 MB/sec - Timed buffered disk reads : 105 MB/sec Kind regards. ॐ -- Swâmi Petaramesh PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majo

Re: duperemove : some real world figures on BTRFS deduplication

do with this, then this is heavy fragmentation. Kind regards. ॐ -- Swâmi Petaramesh PGP 9076E32E -- 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

duperemove : some real world figures on BTRFS deduplication

s. Well the thing "works" and my disk isn't full anymore, so that's a very partial success, but still l wonder if the gain is worth the effort... Best regards. ॐ -- Swâmi Petaramesh PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs

Re: Is stability a joke?

prevents the system from the slowdown effect… My 2 cents. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- 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.k

Re: Help ! "btrfs check" looping recursive

Hi there, Thanks for your reply Duncan ! Le 15/04/2016 02:24, Duncan wrote : > Swâmi Petaramesh posted on Thu, 14 Apr 2016 18:56:29 +0200 as excerpted: > >> It seems that i have a "btrfs check" process that’s stuck in an infinite >> recursive loop… > Given the pr

Help ! "btrfs check" looping recursive

d' dir since it has no valid backref Fixed the nlink of inode 8089093 Can't get file name for inode 8089098, using '8089098' as fallback Moving file '8089098.8089098.8089098.8089098.8089098.8089098.8089098.8089098.8089098.8089098' to 'lost+found' dir since

Re: BTRFS: could not find root 8

Le jeudi 24 décembre 2015, 10:29:02 CET Hugo Mills a écrit : > >systemd is now probing for qgroups on startup. The message is > simply indicating that qgroups are not enabled on the FS. It's harmless. Thanks Hugo. Then it’s harmless but worrying at 1st sight ;-) Kind regar

BTRFS: could not find root 8

[ 29.778795] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready … TIA, kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo inf

Re: BTRFS cannot remove empty directory pretending it is not empty

Le mardi 25 août 2015 15:25:12 Swâmi Petaramesh a écrit : > Uh, I've started it hours ago, and it has been eating 100% CPU on one of my > cores since, without apparently yet finding a single error. btrfs check finally came to an end, and fixed dirs iszes. The 1st good news is that m

Re: BTRFS cannot remove empty directory pretending it is not empty

n. Nobody ever had more backups than I do ;-))) -- which tends to show that I care about my data. However restoring a complete machine with complex filesystems and snapshots remains a tedious process... -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line

Re: BTRFS cannot remove empty directory pretending it is not empty

tes: 4058595328 total fs tree bytes: 3542876160 total extent tree bytes: 225337344 btree space waste bytes: 809904359 file data blocks allocated: 656106184704 referenced 364340379648 Btrfs v3.18.2 Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from th

Re: BTRFS cannot remove empry directory pretending it is not empty

ing my system, and I'd rather keep this "dead" directory forever rather than taking any risk of frying my root FS... Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- 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: BTRFS cannot remove empry directory pretending it is not empty

Le vendredi 21 août 2015 10:47:45 Karsten Heymann a écrit : > > did you check with lsof that no process has an open file descriptor in > that directory? Yes, I even renamed it and rebooted the machine to be double-sure, but to no avail... -- Swâmi Petaramesh http://petarames

BTRFS cannot remove empry directory pretending it is not empty

/ .dropbox-old/instance1/: total 0 drwx-- 1 1000 1000 416 21 août 09:59 . drwx-- 1 1000 1000 18 21 août 09:59 .. # rm -rf .dropbox-old/instance1/ rm: cannot remove ‘.dropbox-old/instance1/’: Directory not empty How could this be fixed ? TIA, kind regards. -- Swâmi Petaramesh -- To

Scrub errors but no errors ?!?

dev/mapper/c_a].generation_errs 0 ...How comes ? TIA for any insight. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- 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 ht

Re: Send/Receive Use Case

iff" between filesystem states, will reflect this difference. Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- 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: Is there a "nossd" option ?

ng mount option causes the mount to fail, thus causing the system boot to fail, thus needing me to boot from a live rescue CD... that would take much longer than writing an half-page email ;-) Best regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from th

Is there a "nossd" option ?

the automatic SSD "choice" that BTRFS makes ? TIA, kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in

BTRFS RAID-1 leaf size change scenario

ights about if this is feasible / how to do it without losing my data... TIA. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- 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

More and more kernel oopses in 3.17.4

-12-05-14:28:42-1102-0 (dup of oops-2014-12-01-12:12:02-1332-0) déc. 05 14:28:43 vajra abrt-dump-journal-oops[1102]: Reported 1 kernel oopses to Abrt -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the

Another BTRFS kernel Oops

abrt-dump-journal-oops[1249]: abrt-dump-journal-oops: Found oopses: 1 déc. 04 08:51:59 vajra abrt-dump-journal-oops[1249]: abrt-dump-journal-oops: Creating problem directories -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E L'espoir luit comme un brin de paille dans l'établ

Re: BRFS balance crash

jra kernel: [] > warn_slowpath_common+0x7d/0xa0 > déc. 01 12:12:32 vajra kernel: [] > warn_slowpath_null+0x1a/0x20 déc. 01 12:12:32 vajra kernel: > [] > btrfs_assert_delayed_root_empty+0x39/0x40 [btrfs] > déc. 01 12:12:32 vajra kernel: [] > btrfs_commit_transaction+0x388/0x950

BRFS balance crash

nel: [] ret_from_fork+0x7c/0xb0 déc. 01 12:12:32 vajra kernel: [] ? kthread_create_on_node+0x1a0/0x1a0 déc. 01 12:12:32 vajra kernel: ---[ end trace f1f27f48a0abdf73 ]--- ...etc. Any indight / help much appreciated. TIA and kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E

Re: Kernel 3.17.2 and RO snapshots

Le dimanche 2 novembre 2014 10:49:52 Hugo Mills a écrit : > > I'm a little lost with latest kernel issues, and would like to know if > > the "data corruption" with RO snapshots is fixed in 3.17.2, or not yet ? > >Yes, it is. Thank you Hugo :-) -- Swâmi Peta

Kernel 3.17.2 and RO snapshots

to go ? And if data corruption occurs, should I expect it to affect snapshots only, or the whole system ? TIA for any insight. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Re: nocow and compression

s.wiki.kernel.org/index.php/Compression#How_does_compression_i > > nt eract_with_direct_IO_or_COW.3F > > ah, sorry, I somehow overlooked this. > > Thanks > > Marc -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Tout être manifesté est là pour embaumer, pour exprimer la Présen

Re: nocow and compression

egards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Quand les doutes sont balayés, la foi véritable réapparaît, confirmée et redressée. Plus rien ne demeure, rien qu'il faille se remémorer. -- Seng-Ts'an, Troisième Patriarche, Le Sin-sin-ming (VIIe s) -- To unsubscribe from thi

Re: Performance Issues

systems, and if something doesn't surprise me at all, it's « slow performance », indeed, although I'm myself more accustomed to « incredibly fscking damn slow performance »... HTH -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Un homme ne doit pas avaler plus de b

Kernel BUG during balance with 3.16.2-1-ARCH

x81/0xa0 sept. 13 16:20:04 tethys kernel: [] system_call_fastpath+0x16/0x1b sept. 13 16:20:04 tethys kernel: Code: 20 38 05 00 e9 78 fe ff ff 0f 1f 00 0f 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b 4c 89 f7 e8 ae 3a 05 00 8b 45 d0 eb aa sept. 13 16:20:04 tethys kernel: RIP [] walk_down_proc+0x31

REPORT: Still a lot of BTRFS freezes in 3.16.1-1-ARCH

any help ? I'm longing for a kernel fix cause I fear something could seriously break in the end... Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord..

BTRFS kernel errors in 3.15.5

ret_from_fork+0x7c/0xb0 juil. 19 09:12:57 zafu kernel: [] ? kthread_create_on_node+0x1b0/0x1b0 -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel

btrfs fi df shows "unknown" ?

# btrfs fi df / Data, single: total=106.00GiB, used=88.28GiB System, DUP: total=32.00MiB, used=24.00KiB Metadata, DUP: total=1.00GiB, used=520.36MiB unknown, single: total=176.00MiB, used=0.00 # btrfs --version Btrfs v3.14.2 # uname -r 3.15.5-200.fc20.x86_64 TIA, kind regards. -- Swâmi Petaram

New BTRFS kernel issues in 3.15.1-1-ARCH

juin 22 10:58:10 zafu kernel: [] ret_from_fork+0x7c/0xb0 juin 22 10:58:10 zafu kernel: [] ? kthread_create_on_node+0x1a0/0x1a0 -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- 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 more snapshot aware defrag ?

an to re-enable the snapshot-awareness of defrag anytime soon ? TIA. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- 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://

Re: BTRFS, SSD and single metadata

ry data in different filesystem sectors, process thru LUKS, will create entirely different binary ciphertext, so for sure both metadata copies will always be different and cannot be "deduped" by SSD firmware... Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Les

Re: BTRFS, SSD and single metadata

UP to SINGLE, or if Id' better stay with DUP... Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- 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

BTRFS, SSD and single metadata

SSD being a Micron RealSSD C400 For both SSD preservation and data integrity, would it be advisable to change metadata to "SINGLE" using a rebalance, or if I'd better just leave things the way they are...? TIA for any insight. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Tou

Re: Using BTRFS on SSD now ?

Le jeudi 5 juin 2014 17:59:48 Christoph Anton Mitterer a écrit : > Be aware, that discard used with dm-crypt may have security > implications. Thanks, I knew :-) -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Le sage n’est pas celui qui discrimine, c’est celui qui réunit les la

Re: Using BTRFS on SSD now ?

g the same key is to put both of them on an LVM itself luks- encrypted using dm-crypt. All my machines have been made this way for *years*, so I know it works damn well ;-) ...And it also allows for hibernateing the system to (encrypted) swap space... That's a pretty fine setup :-) -

Using BTRFS on SSD now ?

Is there any pro/cons currently, on a 3.14 kernel, about using BTRFS along with an SSD ? Is there specific advice about leaf size, use of compression, snapshots, (auto-)defrag etc, that might be relevant especially for SSDs ? TIA. -- Swâmi Petaramesh http://petaramesh.org PGP 9076

3.14.4 Kernel BUG at fs/namei.c : KDE's kate + ecryptfs + BTRFS + LVM2 + LUKS

> 0b 66 0f 1f 44 00 00 b8 kernel: RIP [] may_delete+0x138/0x150 kernel: RSP kernel: ---[ end trace 73914218811ba28d ]--- -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to maj

Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?

ask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount- ro 0 0 $ uname -r 3.14.1-1-ARCH -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org M

How to make BTRFS crawl

ed... Your system will be dead with saturated HD access for several *minutes* ...Hope this may help hunting this down... Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body

mount options ignored / unclear

pecified in fstab ? That's a bug, as far as I can tell. Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- 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: Using noCow with snapshots ?

ll be a problem longer > term. > > Which is why I suggest putting such files on a separate subvolume and not > snapshotting that subvolume, since snapshots stop at the subvolume > boundary. That gives NOCOW a chance to actually *BE* NOCOW. -- Swâmi Petaramesh http://petaramesh.o

Using noCow with snapshots ?

ied in the snapshot as well, efectively defeating the snapshot ? 2/ Being snapshotted, will the database be COWed even though it's supposed to be noCow ? 3/ Are both options mutually incompatible in some more osbcure ways ? I'd like to know where I'm going with this ;-) TIA and

Re: Scrub bug on kernel 3.13

n : Explicitly installed Install Script : Yes Validated By : Signature Thanks again :-) -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E signature.asc Description: This is a digitally signed message part.

Re: Scrub bug on kernel 2.13

Sorry, I meant kernel 3.13 :-) Linux zafu 3.13.8-1-ARCH #1 SMP PREEMPT Tue Apr 1 12:19:51 CEST 2014 x86_64 GNU/Linux Le lundi 7 avril 2014 10:32:04 Swâmi Petaramesh a écrit : > Hi there, > > Machine got rebooted while scrub was in process, and now it looks like a > scrub zombie...

Scrub bug on kernel 2.13

fs scrub status [-d] /'. root@zafu:~# btrfs scrub status / scrub status for 13c87f57-3a85-4daf-a4bf-ba777407c169 scrub started at Mon Apr 7 09:49:48 2014, running for 693 seconds total bytes scrubbed: 34.06GiB with 0 errors -- Swâmi Petaramesh http://petaramesh.org

Re: BTRFS setup advice for laptop performance ?

ning KMail and Firefox - but if it aint' no good at this very basic usage, well what is it good at ? I'm not ranting because I love to shoot BTRFS down in flames, but because I'd love to be able to keep it on my system this time, and forget it, and not to reformat everything again

Re: BTRFS setup advice for laptop performance ?

shouldn't go to the sea as the engine will rust, and you shouldn't drive too much in cities as it will smoke too much... and not too much motorways either as the motor might heat a bit too much. I need a filesystem that fits me, I don't want to have to fit my filesystem :-\

Re: BTRFS setup advice for laptop performance ?

uot;normally responsive" to "dreadfully slow" over time, that starting any app takes over a full minute with HD LED steady lit, that booting bhas become so long that the GUI DM dies of timeout before it even starts, and you have to restart it manualle... you can tell it's gone

Re: BTRFS setup advice for laptop performance ?

case... But if even this has a noticeable negative impact on BTRFS performance, then what the hell are BTRFS snapshots good at ?? Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in t

BTRFS setup advice for laptop performance ?

options I should pass before starting to populate the FS with a system and data ? - Generally speaking, does LZO compression improve or degrade performance ? I'm not able to figure it out clearly. TIA for the insight. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscrib

Rebalance makes BTRFS 10x slower

operate, to the point it has become hardly usable :-( I would have thought a rebalance would have improved the filesystem organization, looks like it's the absolute contrary :-( -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "u

Re: Kernel BUG: btrfs send - Incremental backup

0 nr 4096 ram 4096 > extent compression 0 > > That is what I'm looking for, you will have multiple of these. Thanks, > > Josef -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- 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: Kernel BUG: btrfs send - Incremental backup

MiB, used=0.00 Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- 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

  1   2   >