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

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

[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

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

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)

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)

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

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)

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)

.2 kernel...) -- ॐ 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)

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)

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)

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)

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: [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)

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

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

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

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: [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)

ay be very annoying and very time consuming rebuilding. 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)

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)

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)

#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: 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)

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

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)

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)

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

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)

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)

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)

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)

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)

definitely some bug out there. ॐ -- 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: 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

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

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)

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

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

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

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

BTRFS and the steadily lit LED

of the time in mode « Working my patience while waiting for the HD LED to go off ». I haven't noticed any real-life noticeable improvement upgrading the kernels from 3.5.x to 3.8.x So I'm wondering... -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis

This time HD LED doesn't come up at all :-(

ng to reinstall from backups ? 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

Re: This time HD LED doesn't come up at all :-(

way (3.8.0 kernel) fails, and I get these errors... At least the FS doesn't look plain dead, but I have no clue... Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsubscribe from this list: send the line "uns

Re: This time HD LED doesn't come up at all :-(

inode_cache 30 20 0:16 /@owner_.VBox /storage/owner_.VBox rw,noatime - btrfs /dev/sda1 rw,compress=lzo,space_cache,autodefrag,inode_cache 31 20 0:16 /@owner_BIG /storage/owner_BIG rw,noatime - btrfs /dev/sda1 rw,compress=lzo,space_cache,autodefrag,inode_cache -- Swâmi Petaramesh http://petaramesh.or

scrub "correcting" tons of errors ?

ng found and corrected 22926 CSUM errors ??!?!?!?!!??? This is a rather new HDD, in perfect shape (SMART all OK, never reallocated a single sector, less than 200 hours total runtime...) WTF ?!? I've cancelled scrub for now, until I get further understanding of what can be happening... -- Swâmi Peta

Re: scrub "correcting" tons of errors ?

that it had been imaged, then restored, using partclone.btrfs (which itself is supposed to use the BTRFS libraries). I have a screenshot of "last thing I saw when it hanged", I can upload it somewhere, should it be relevant... Kind regards. -- Swâmi Petaramesh http://petaramesh.org PG

Re: scrub "correcting" tons of errors ?

you know if it hangs agan and I can put the hand on something. Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@v

Re: scrub "correcting" tons of errors ?

Le 29/03/2013 14:12, Josef Bacik a écrit : > Screenshots are welcome This time I good a real nice kernel Ooops during scrub... http://dl.free.fr/hjAdOH3mG (use your email address or the list's one to fetch it) -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas

Re: scrub "correcting" tons of errors ?

crash it once more... I'll hopefully be back on this soon. Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message

Moving...

ots, to no avail... So I'm in process of moving the 3 main laptops in here from BTRFS to ZFS... Kind regards to all. -- 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 major

Re: Moving...

akes 75 MORE seconds. You get it. Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- 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: [zfs-discuss] Re: Moving...

ily since 1996, all distros, on every imaginable hardware (but not on modern SSDs). I've never seen such performance anywhere. Would be extremely curious about the distro, filesystem and setup of the "9 year old laptop fitted with a very slow PATA SSD" that boots to GDM in 9 seconds..

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

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

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

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

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

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

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

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

BTRFS fsck apparent errors

Hi there, A couple days ago, I have converted my Ubuntu Precise machine from ext4 to BTRFS using btrfs-convert. I currently use kernel: Linux fnix 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux ...and a btrfs-tools package more recent than the ol

Re: BTRFS fsck apparent errors

to fix ? "man btrfsck" or "btrfsck -h" do not show any option, only a device name... 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 info at http://vger.kernel.org/majordomo-info.html

Change "small" filesystem to normal

ere a way tp do this without reformatting the FS ? TIA, kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord.

Re: Change "small" filesystem to normal

dov a écrit : On Sun, 22 Jul 2012 17:06:24 +0200 Swâmi Petaramesh wrote: Hi, I've created a "small" BTRFS filesystem, where metadata+data are mixed (and metadata are not DUP'ed). Then I've enlarged the FS to 1 GB ; now I'd like to make it "normal"

Re: subvolumes: default and IDs

ng and should > be easy to fix... I've fallen upon this one as well. That's typically the kind of bug that makes one wonder to what extent the software has ever been tested, and doubt it's anything close to production quality... :-/ -- Swâmi Petaramesh http://petaramesh.org PGP

"free space cache generation" ?

Hi there, I noticed my syslog is filling up with tons of: btrfs: free space inode generation (0) did not match free space cache generation (25326) ...any clue ? TIA. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.or

Re: "free space cache generation" ?

Le 19/09/2012 18:01, Josef Bacik a écrit : > Yeah I need to just put those under a DEBUG ifdef, they aren't a big > deal, just letting you know that the on disk cache is invalid and it > will have to put it together ye olde fashioned way. ...But is it supposed to, and how to fix i

Re: "free space cache generation" ?

laining that some trees (corresponding to removed snapshots as far as I could tell) were b0rked, and btrfsck couldn't help... So I lost the FS - and lost quite a bit of confidence into BTRFS the same day... :-\ -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne

Help understanding btrfsck output...

ee bytes: 1376681984 btree space waste bytes: 382927315 file data blocks allocated: 103024238592 referenced 102409895936 Btrfs Btrfs v0.19 -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsubscribe from this list: send the line &quo

BTRFS, getting darn slower everyday

it had improved so was back to BTRFS, and I wouldn't have to revert back again :-/ Any advice or help greatly appreciated. TIA. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsubscribe from this list: send the line "uns

Re: BTRFS, getting darn slower everyday

ime0 0 /dev/VG1/BTR_POOL/data/VBOX_VMSbtrfs subvol=DATA/VBOX_VMS,space_cache,compress=lzo,noatime0 0 -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsubscribe from this list: send the line "unsubscribe lin

Re: BTRFS, getting darn slower everyday

x27;m not sure that "a bit" quicker will be enough, when I see my BTRFS is currently about 8x slower than what ext4 user to... -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsubscribe from this list: send the line &qu

Re: BTRFS, getting darn slower everyday

U/@/.snapshots/625/snapshot ID 3238 top level 5 path UBUNTU/@home/.snapshots/624/snapshot ID 3239 top level 5 path STORAGE/.snapshots/659/snapshot ID 3240 top level 5 path UBUNTU/@/.snapshots/626/snapshot ID 3241 top level 5 path UBUNTU/@home/.snapshots/625/snapshot ID 3242 top level 5 path STORAGE/.s

Re: BTRFS, getting darn slower everyday

but it would defeat one of the prominent purposes for which I use BTRFS, and the number of snapshots would grow immediately again, as I use the excellent OpenSuSE "snapper" tool, that makes a snapshot every single hour... Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076

Re: BTRFS, getting darn slower everyday

. The 4 concerned machines have either 4GB or 2GB RAM. None is heavily loaded as far as RAM is concerned (just booting into a standard Ubuntu GUI and then accessing emailn, browser, office applications etc.) Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas :

Re: BTRFS, getting darn slower everyday

7;m under the impression that it's painfully slow. Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...

Re: BTRFS, getting darn slower everyday

d some not ? That's to bad :-( > I fear that both the combination of autodefrag and the high number of > snapshot could be the root-cause of the the bad performance. As a test, I will try to remove *most* of my snapshots and see if it helps... Thanks for the suggestion ! Kind re

Re: BTRFS, getting darn slower everyday

re reactive and swift. So it seems that the number or active snapshots (or is it the number of subvols whatsoever ??) dramatically impacts performance... Thanks for the suggestion. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsub

Re: BTRFS, getting darn slower everyday

probable that all of them would get their cache ignored...?) Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...

inode_cache

Hi there, On a performance standpoint - and on Ubuntu Quantall kernel 3.5.0-17 - is it advisable to mount BTRFS with "inode_cache" ? Is there any risk or counterpart doing so ? TIA, kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne su

BTRFS cache problem

Any clue ? TIA. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- 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 cache problem

Le 11/11/2012 15:05, Bart Noordervliet a écrit : > which kernel version are you running? Hi Bart, # uname -srv Linux 3.5.0-18-generic #29-Ubuntu SMP Fri Oct 19 10:26:51 UTC 2012 -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. --

Re: BTRFS cache problem

my main laptop which I badly need to be in working order tomorrow morning (and #me having slept at night... ;-) -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs&quo

Re: BTRFS cache problem

finish rebuilding the cache. Finally, remove all mention of the caches > from your fstab and kernel command line before you next mount the FS. > Hugo. Thanks very much Hugo, I'll give this a try. Should I assume that the cache clearing / building is complete as soon as the disk

Re: BTRFS cache problem

improve (quickly) over time... But for now I have to admit that I regret my choice performance wise (which is terrible...) and stability wise (Already 2 reinstalls with complete format, if there's a next one, the next one will be ZFS...) Kind regards. -- Swâmi Petaramesh http://petaramesh

Re: BTRFS cache problem

u next mount the FS. Unfortunately, same issue after applying your suggestions... [ 752.943532] btrfs: free space inode generation (0) did not match free space cache generation (203710) -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- To

Example of BTRFS uglyssima performance : Bitcoin

he initial loading of the DB took them a couple hours... With BTRFS it's been 5x24 hours and counting... :-( This filesystem is pure crap as soon as it comes to database processing :-( Kind regards. -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur F

  1   2   >