Re: [PATCH RESEND 0/8] btrfs-progs: sub: Relax the privileges of "subvolume list/show"

Misono Tomohiro - 27.11.18, 06:24: > Importantly, in order to make output consistent for both root and > non-privileged user, this changes the behavior of "subvolume list": > - (default) Only list in subvolume under the specified path. >Path needs to be a subvolume. Does that work

Re: Interpreting `btrfs filesystem show'

Hugo Mills - 15.10.18, 16:26: > On Mon, Oct 15, 2018 at 05:24:08PM +0300, Anton Shepelev wrote: > > Hello, all > > > > While trying to resolve free space problems, and found that > > > > I cannot interpret the output of: > > > btrfs filesystem show > > > > Label: none uuid:

Re: BTRFS related kernel backtrace on boot on 4.18.7 after blackout due to discharged battery

Filipe Manana - 05.10.18, 17:21: > On Fri, Oct 5, 2018 at 3:23 PM Martin Steigerwald wrote: > > Hello! > > > > On ThinkPad T520 after battery was discharged and machine just > > blacked out. > > > > Is that some sign of regular consistency check / replay

BTRFS related kernel backtrace on boot on 4.18.7 after blackout due to discharged battery

Hello! On ThinkPad T520 after battery was discharged and machine just blacked out. Is that some sign of regular consistency check / replay or something to investigate further? I already scrubbed all data and there are no errors. Also btrfs device stats reports no errors. SMART status appears to

Re: very poor performance / a lot of writes to disk with space_cache (but not with space_cache=v2)

Hans van Kranenburg - 19.09.18, 19:58: > However, as soon as we remount the filesystem with space_cache=v2 - > > > writes drop to just around 3-10 MB/s to each disk. If we remount to > > space_cache - lots of writes, system unresponsive. Again remount to > > space_cache=v2 - low writes, system

Re: lazytime mount option—no support in Btrfs

waxhead - 18.08.18, 22:45: > Adam Hunt wrote: > > Back in 2014 Ted Tso introduced the lazytime mount option for ext4 > > and shortly thereafter a more generic VFS implementation which was > > then merged into mainline. His early patches included support for > > Btrfs but those changes were removed

Re: Experiences on BTRFS Dual SSD RAID 1 with outage of one SSD

Roman Mamedov - 18.08.18, 09:12: > On Fri, 17 Aug 2018 23:17:33 +0200 > > Martin Steigerwald wrote: > > > Do not consider SSD "compression" as a factor in any of your > > > calculations or planning. Modern controllers do not do it anymore, > > > th

Re: Experiences on BTRFS Dual SSD RAID 1 with outage of one SSD

Austin S. Hemmelgarn - 17.08.18, 14:55: > On 2018-08-17 08:28, Martin Steigerwald wrote: > > Thanks for your detailed answer. > > > > Austin S. Hemmelgarn - 17.08.18, 13:58: > >> On 2018-08-17 05:08, Martin Steigerwald wrote: […] > >>> Anyway, creating

Re: Experiences on BTRFS Dual SSD RAID 1 with outage of one SSD

Hi Roman. Now with proper CC. Roman Mamedov - 17.08.18, 14:50: > On Fri, 17 Aug 2018 14:28:25 +0200 > > Martin Steigerwald wrote: > > > First off, keep in mind that the SSD firmware doing compression > > > only > > > really helps with wear-leveling. Doing

Re: Experiences on BTRFS Dual SSD RAID 1 with outage of one SSD

Austin S. Hemmelgarn - 17.08.18, 15:01: > On 2018-08-17 08:50, Roman Mamedov wrote: > > On Fri, 17 Aug 2018 14:28:25 +0200 > > > > Martin Steigerwald wrote: > >>> First off, keep in mind that the SSD firmware doing compression > >>> only

Re: Experiences on BTRFS Dual SSD RAID 1 with outage of one SSD

Thanks for your detailed answer. Austin S. Hemmelgarn - 17.08.18, 13:58: > On 2018-08-17 05:08, Martin Steigerwald wrote: […] > > I have seen a discussion about the limitation in point 2. That > > allowing to add a device and make it into RAID 1 again might be > > dange

Experiences on BTRFS Dual SSD RAID 1 with outage of one SSD

Hi! This happened about two weeks ago. I already dealt with it and all is well. Linux hung on suspend so I switched off this ThinkPad T520 forcefully. After that it did not boot the operating system anymore. Intel SSD 320, latest firmware, which should patch this bug, but apparently does not,

Re: BTRFS and databases

Andrei Borzenkov - 02.08.18, 12:35: > Отправлено с iPhone > > > 2 авг. 2018 г., в 12:16, Martin Steigerwald > > написал(а):> > > Hugo Mills - 01.08.18, 10:56: > >>> On Wed, Aug 01, 2018 at 05:45:15AM +0200, MegaBrutal wrote: > >>> I know it

Re: BTRFS and databases

Hugo Mills - 01.08.18, 10:56: > On Wed, Aug 01, 2018 at 05:45:15AM +0200, MegaBrutal wrote: > > I know it's a decade-old question, but I'd like to hear your > > thoughts > > of today. By now, I became a heavy BTRFS user. Almost everywhere I > > use BTRFS, except in situations when it is obvious

Re: Healthy amount of free space?

Nikolay Borisov - 17.07.18, 10:16: > On 17.07.2018 11:02, Martin Steigerwald wrote: > > Nikolay Borisov - 17.07.18, 09:20: > >> On 16.07.2018 23:58, Wolf wrote: > >>> Greetings, > >>> I would like to ask what what is healthy amount of free space to >

Re: Healthy amount of free space?

Hi Nikolay. Nikolay Borisov - 17.07.18, 09:20: > On 16.07.2018 23:58, Wolf wrote: > > Greetings, > > I would like to ask what what is healthy amount of free space to > > keep on each device for btrfs to be happy? > > > > This is how my disk array currently looks like > > > > [root@dennas

Re: [PATCH v2 1/2] btrfs: Check each block group has corresponding chunk at mount time

Nikolay Borisov - 03.07.18, 11:08: > On 3.07.2018 11:47, Qu Wenruo wrote: > > On 2018年07月03日 16:33, Nikolay Borisov wrote: > >> On 3.07.2018 11:08, Qu Wenruo wrote: > >>> Reported in https://bugzilla.kernel.org/show_bug.cgi?id=199837, if > >>> a > >>> crafted btrfs with incorrect chunk<->block

Re: "decompress failed" in 1-2 files always causes kernel oops, check/scrub pass

Hey James. james harvey - 12.05.18, 07:08: > 100% reproducible, booting from disk, or even Arch installation ISO. > Kernel 4.16.7. btrfs-progs v4.16. > > Reading one of two journalctl files causes a kernel oops. Initially > ran into it from "journalctl --list-boots", but cat'ing the file does

Re: Read before you deploy btrfs + zstd

David Sterba - 15.11.17, 15:39: > On Tue, Nov 14, 2017 at 07:53:31PM +0100, David Sterba wrote: > > On Mon, Nov 13, 2017 at 11:50:46PM +0100, David Sterba wrote: > > > Up to now, there are no bootloaders supporting ZSTD. > > > > I've tried to implement the support to GRUB, still incomplete and

Re: Read before you deploy btrfs + zstd

David Sterba - 14.11.17, 19:49: > On Tue, Nov 14, 2017 at 08:34:37AM +0100, Martin Steigerwald wrote: > > Hello David. > > > > David Sterba - 13.11.17, 23:50: > > > while 4.14 is still fresh, let me address some concerns I've seen on > > > linux > > &

Re: Read before you deploy btrfs + zstd

Hello David. David Sterba - 13.11.17, 23:50: > while 4.14 is still fresh, let me address some concerns I've seen on linux > forums already. > > The newly added ZSTD support is a feature that has broader impact than > just the runtime compression. The btrfs-progs understand filesystem with > ZSTD

Re: Data and metadata extent allocators [1/2]: Recap: The data story

Hello Hans, Hans van Kranenburg - 27.10.17, 20:17: > This is a followup to my previous threads named "About free space > fragmentation, metadata write amplification and (no)ssd" [0] and > "Experiences with metadata balance/convert" [1], exploring how good or > bad btrfs can handle filesystems

Something like ZFS Channel Programs for BTRFS & probably XFS or even VFS?

[repost. I didn´t notice autocompletion gave me wrong address for fsdevel, blacklisted now] Hello. What do you think of http://open-zfs.org/wiki/Projects/ZFS_Channel_Programs ? There are quite some BTRFS maintenance programs like the deduplication stuff. Also regular scrubs… and in certain

Something like ZFS Channel Programs for BTRFS & probably XFS or even VFS?

Hello. What do you think of http://open-zfs.org/wiki/Projects/ZFS_Channel_Programs ? There are quite some BTRFS maintenance programs like the deduplication stuff. Also regular scrubs… and in certain circumstances probably balances can make sense. In addition to this XFS got scrub

Re: 4.11.6 / more corruption / root 15455 has a root item with a more recent gen (33682) compared to the found root node (0)

Hello Duncan. Duncan - 09.07.17, 11:17: > Paul Jones posted on Sun, 09 Jul 2017 09:16:36 + as excerpted: > >> Marc MERLIN - 08.07.17, 21:34: > >> > This is now the 3rd filesystem I have (on 3 different machines) that > >> > is getting corruption of some kind (on 4.11.6). > >> > >> Anyone

Re: 4.11.6 / more corruption / root 15455 has a root item with a more recent gen (33682) compared to the found root node (0)

Hello Marc. Marc MERLIN - 08.07.17, 21:34: > Sigh, > > This is now the 3rd filesystem I have (on 3 different machines) that is > getting corruption of some kind (on 4.11.6). Anyone else getting corruptions with 4.11? I happily switch back to 4.10.17 or even 4.9 if that is the case. I may even

Re: runtime btrfsck

Stefan Priebe - Profihost AG - 10.05.17, 09:02: > I'm now trying btrfs progs 4.10.2. Is anybody out there who can tell me > something about the expected runtime or how to fix bad key ordering? I had a similar issue which remained unresolved. But I clearly saw that btrfs check was running in a

Re: [4.9] btrfs check --repair looping over file extent discount errors

Martin Steigerwald - 22.04.17, 20:01: > Chris Murphy - 22.04.17, 09:31: > > Is the file system created with no-holes? > > I have how to find out about it and while doing accidentally set that I didn´t find out how to find out about it and… > feature on another filesystem (bt

Re: [4.9] btrfs check --repair looping over file extent discount errors

Hello Chris. Chris Murphy - 22.04.17, 09:31: > Is the file system created with no-holes? I have how to find out about it and while doing accidentally set that feature on another filesystem (btrfstune only seems to be able to enable the feature, not show the current state of it). But as there

Re: [4.9] btrfs check --repair looping over file extent discount errors

ASAP. Thanks, Martin Martin Steigerwald - 14.04.17, 21:35: > Hello, > > backup harddisk connected via eSATA. Hard kernel hang, mouse pointer > freezing two times seemingly after finishing /home backup and creating new > snapshot on source BTRFS SSD RAID 1 for / in order to b

[4.9] btrfs check --repair looping over file extent discount errors

Hello, backup harddisk connected via eSATA. Hard kernel hang, mouse pointer freezing two times seemingly after finishing /home backup and creating new snapshot on source BTRFS SSD RAID 1 for / in order to backup it. I did scrubbed / and it appears to be okay, but I didn´t run btrfs check on

Re: Convert from RAID 5 to 10

Am Mittwoch, 30. November 2016, 12:09:23 CET schrieb Chris Murphy: > On Wed, Nov 30, 2016 at 7:37 AM, Austin S. Hemmelgarn > > wrote: > > The stability info could be improved, but _absolutely none_ of the things > > mentioned as issues with raid1 are specific to raid1. And

Re: Convert from RAID 5 to 10

as excerpted: > >>>> Am 30/11/16 um 09:06 schrieb Martin Steigerwald: > >>>>> Am Mittwoch, 30. November 2016, 10:38:08 CET schrieb Roman Mamedov: […] > >> It is really disappointing to not have this information in the wiki > >> itself. This w

Re: Convert from RAID 5 to 10

Am Mittwoch, 30. November 2016, 10:38:08 CET schrieb Roman Mamedov: > On Wed, 30 Nov 2016 00:16:48 +0100 > > Wilson Meier wrote: > > That said, btrfs shouldn't be used for other then raid1 as every other > > raid level has serious problems or at least doesn't work as the

Re: degraded BTRFS RAID 1 not mountable: open_ctree failed, unable to find block group for 0

Am Donnerstag, 17. November 2016, 12:05:31 CET schrieb Chris Murphy: > I think the wiki should be updated to reflect that raid1 and raid10 > are mostly OK. I think it's grossly misleading to consider either as > green/OK when a single degraded read write mount creates single chunks > that will

Re: degraded BTRFS RAID 1 not mountable: open_ctree failed, unable to find block group for 0

Am Mittwoch, 16. November 2016, 07:57:08 CET schrieb Austin S. Hemmelgarn: > On 2016-11-16 06:04, Martin Steigerwald wrote: > > Am Mittwoch, 16. November 2016, 16:00:31 CET schrieb Roman Mamedov: > >> On Wed, 16 Nov 2016 11:55:32 +0100 > >> > >> Martin Steig

Re: degraded BTRFS RAID 1 not mountable: open_ctree failed, unable to find block group for 0

gt; btrfs scrub status /dev/satafp1/daten scrub status for […] scrub started at Wed Nov 16 12:13:27 2016, running for 00:00:10 total bytes scrubbed: 45.53MiB with 0 errors It would be helpful to receive a proper error message on this one. Okay, seems today I learned quite something abou

Re: degraded BTRFS RAID 1 not mountable: open_ctree failed, unable to find block group for 0

Am Mittwoch, 16. November 2016, 16:00:31 CET schrieb Roman Mamedov: > On Wed, 16 Nov 2016 11:55:32 +0100 > > Martin Steigerwald <martin.steigerw...@teamix.de> wrote: > > I do think that above kernel messages invite such a kind of interpretation > > tough. I took th

Re: degraded BTRFS RAID 1 not mountable: open_ctree failed, unable to find block group for 0

Am Mittwoch, 16. November 2016, 15:43:36 CET schrieb Roman Mamedov: > On Wed, 16 Nov 2016 11:25:00 +0100 > > Martin Steigerwald <martin.steigerw...@teamix.de> wrote: > > merkaba:~> mount -o degraded,clear_cache /dev/satafp1/backup /mnt/zeit > > mount: Fals

degraded BTRFS RAID 1 not mountable: open_ctree failed, unable to find block group for 0

We seem to be looping a lot on daten-restore/[…]/virtualbox-4.1.18-dfsg/out/lib/vboxsoap.a, do you want to keep going on ? (y/N/a): after about 35 GiB of data restored. I answered no to this one and now it is at about 53 GiB already. I just got another one of these, but also not concerning a

Re: stability matrix

Am Donnerstag, 15. September 2016, 07:54:26 CEST schrieb Austin S. Hemmelgarn: > On 2016-09-15 05:49, Hans van Kranenburg wrote: > > On 09/15/2016 04:14 AM, Christoph Anton Mitterer wrote: […] > I specifically do not think we should worry about distro kernels though. > If someone is using a

Re: Is stability a joke?

Am Donnerstag, 15. September 2016, 07:55:36 CEST schrieb Kai Krakow: > Am Mon, 12 Sep 2016 08:20:20 -0400 > > schrieb "Austin S. Hemmelgarn" <ahferro...@gmail.com>: > > On 2016-09-11 09:02, Hugo Mills wrote: > > > On Sun, Sep 11, 2016 at 02:39:14PM +0200,

Re: Is stability a joke?

Hello Nicholas. Am Mittwoch, 14. September 2016, 21:05:52 CEST schrieb Nicholas D Steeves: > On Mon, Sep 12, 2016 at 08:20:20AM -0400, Austin S. Hemmelgarn wrote: > > On 2016-09-11 09:02, Hugo Mills wrote: […] > > As far as documentation though, we [BTRFS] really do need to get our act > >

Re: Is stability a joke? (wiki updated)

Am Dienstag, 13. September 2016, 07:28:38 CEST schrieb Austin S. Hemmelgarn: > On 2016-09-12 16:44, Chris Murphy wrote: > > On Mon, Sep 12, 2016 at 2:35 PM, Martin Steigerwald <mar...@lichtvoll.de> wrote: > >> Am Montag, 12. September 2016, 23:21:09 CEST schrieb Pasi Kärkk

Re: Is stability a joke? (wiki updated)

Am Montag, 12. September 2016, 23:21:09 CEST schrieb Pasi Kärkkäinen: > On Mon, Sep 12, 2016 at 09:57:17PM +0200, Martin Steigerwald wrote: > > Am Montag, 12. September 2016, 18:27:47 CEST schrieb David Sterba: > > > On Mon, Sep 12, 2016 at 04:27:14PM +0200, David Sterba

Re: Is stability a joke? (wiki updated)

Am Montag, 12. September 2016, 18:27:47 CEST schrieb David Sterba: > On Mon, Sep 12, 2016 at 04:27:14PM +0200, David Sterba wrote: > > > I therefore would like to propose that some sort of feature / stability > > > matrix for the latest kernel is added to the wiki preferably somewhere > > > where

Re: Small fs

Am Sonntag, 11. September 2016, 19:46:32 CEST schrieb Hugo Mills: > On Sun, Sep 11, 2016 at 09:13:28PM +0200, Martin Steigerwald wrote: > > Am Sonntag, 11. September 2016, 16:44:23 CEST schrieb Duncan: > > > * Metadata, and thus mixed-bg, defaults to DUP mode on a single-devic

compress=lzo safe to use? (was: Re: Trying to rescue my data :()

Am Sonntag, 26. Juni 2016, 13:13:04 CEST schrieb Steven Haigh: > On 26/06/16 12:30, Duncan wrote: > > Steven Haigh posted on Sun, 26 Jun 2016 02:39:23 +1000 as excerpted: > >> In every case, it was a flurry of csum error messages, then instant > >> death. > > > > This is very possibly a known bug

Re: Small fs

Am Sonntag, 11. September 2016, 21:56:07 CEST schrieb Imran Geriskovan: > On 9/11/16, Duncan <1i5t5.dun...@cox.net> wrote: > > Martin Steigerwald posted on Sun, 11 Sep 2016 17:32:44 +0200 as excerpted: > >>> What is the smallest recommended fs size for btrfs? &

Re: Small fs

Am Sonntag, 11. September 2016, 16:44:23 CEST schrieb Duncan: > * Metadata, and thus mixed-bg, defaults to DUP mode on a single-device > filesystem (except on ssd where I actually still use it myself, and > recommend it except for ssds that do firmware dedupe). In mixed-mode > this means two

Re: Small fs

Am Sonntag, 11. September 2016, 18:27:30 CEST schrieben Sie: > What is the smallest recommended fs size for btrfs? > > - There are mentions of 256MB around the net. > - Gparted reserves minimum of 256MB for btrfs. > > With an ordinary partition on a single disk, > fs created with just

Re: Is stability a joke?

Am Sonntag, 11. September 2016, 16:54:25 CEST schrieben Sie: > Am Sonntag, 11. September 2016, 14:39:14 CEST schrieb Waxhead: > > Martin Steigerwald wrote: > > > Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin Steigerwald: > > >>>>> The Nouv

Re: Is stability a joke?

Am Sonntag, 11. September 2016, 13:02:21 CEST schrieb Hugo Mills: > On Sun, Sep 11, 2016 at 02:39:14PM +0200, Waxhead wrote: > > Martin Steigerwald wrote: > > >Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin Steigerwald: > > >>>>Thing is: This just

Re: Is stability a joke?

Am Sonntag, 11. September 2016, 14:39:14 CEST schrieb Waxhead: > Martin Steigerwald wrote: > > Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin Steigerwald: > >>>>> The Nouveau graphics driver have a nice feature matrix on it's webpage > >>>&

Re: Is stability a joke?

Am Sonntag, 11. September 2016, 14:30:51 CEST schrieb Waxhead: > > I think what would be a good next step would be to ask developers / users > > about feature stability and then update the wiki. If thats important to > > you, I suggest you invest some energy in doing that. And ask for help. > >

Re: Is stability a joke?

Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin Steigerwald: > > >> The Nouveau graphics driver have a nice feature matrix on it's webpage > > >> and I think that BTRFS perhaps should consider doing something like > > >> that > > >>

Re: Is stability a joke?

Am Sonntag, 11. September 2016, 13:21:30 CEST schrieb Zoiled: > Martin Steigerwald wrote: > > Am Sonntag, 11. September 2016, 10:55:21 CEST schrieb Waxhead: > >> I have been following BTRFS for years and have recently been starting to > >> use BTRFS more and more and

Re: Is stability a joke?

Am Sonntag, 11. September 2016, 10:55:21 CEST schrieb Waxhead: > I have been following BTRFS for years and have recently been starting to > use BTRFS more and more and as always BTRFS' stability is a hot topic. > Some says that BTRFS is a dead end research project while others claim > the

Re: kworker threads may be working saner now instead of using 100% of a CPU core for minutes (Re: Still not production ready)

Am Mittwoch, 7. September 2016, 11:53:04 CEST schrieb Christian Rohmann: > On 03/20/2016 12:24 PM, Martin Steigerwald wrote: > >> btrfs kworker thread uses up 100% of a Sandybridge core for minutes on > >> > >> > random write into big file > >> > http

Re: dd on wrong device, 1.9 GiB from the beginning has been overwritten, how to restore partition?

Hi Maximilian, On Sonntag, 12. Juni 2016 23:22:11 CEST Maximilian Böhm wrote: > Hi there, I did something terribly wrong, all blame on me. I wanted to > write to an USB stick but /dev/sdc wasn't the stick in this case but > an attached HDD with GPT and an 8 TB btrfs partition… > > $ sudo dd

Re: RFE: 'btrfs' tools machine readable output

Hello Richard, On Montag, 16. Mai 2016 13:14:56 CEST Richard W.M. Jones wrote: > I don't have time to implement this right now, so I'm just posting > this as a suggestion/request ... > > It would be really helpful if the btrfs tools had a machine-readable > output. > > Libguestfs parses btrfs

Re: btrfs send/receive using generation number as source

On Freitag, 8. April 2016 11:12:54 CEST Hugo Mills wrote: > On Fri, Apr 08, 2016 at 01:01:03PM +0200, Martin Steigerwald wrote: > > Hello! > > > > As far as I understood, for differential btrfs send/receive – I didn´t use > > it yet – I need to keep a snapshot on the

btrfs send/receive using generation number as source

Hello! As far as I understood, for differential btrfs send/receive – I didn´t use it yet – I need to keep a snapshot on the source device to then tell btrfs send to send the differences between the snapshot and the current state. Now the BTRFS filesystems on my SSDs are often quite full, thus

Re: csum errors in VirtualBox VDI files

On Dienstag, 22. März 2016 09:03:42 CEST Kai Krakow wrote: > Hello! > > Since one of the last kernel updates (I don't know which exactly), I'm > experiencing csum errors within VDI files when running VirtualBox. A > side effect of this is, as soon as dmesg shows these errors, commands > like "du"

Re: New file system with same issue (was: Again, no space left on device while rebalancing and recipe doesnt work)

On Dienstag, 15. März 2016 08:07:22 CEST Marc Haber wrote: > On Mon, Mar 14, 2016 at 09:39:51PM +0100, Henk Slager wrote: > > >> BTW, I restored and mounted your 20160307-fanbtr-image: > > >> > > >> [266169.207952] BTRFS: device label fanbtr devid 1 transid 22215732 > > >> /dev/loop0

Re: unable to mount btrfs partition, please help :(

On Sonntag, 20. März 2016 10:18:26 CET Patrick Tschackert wrote: > > I think in retrospect the safe way to do these kinds of Virtual Box > > updates, which require kernel module updates, would have been to > > shutdown the VM and stop the array. *shrug* > > > After this, I think I'll just do

Re: unable to mount btrfs partition, please help :(

On Samstag, 19. März 2016 19:34:55 CET Chris Murphy wrote: > >>> $ uname -a > >>> Linux vmhost 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4 > >>> (2016-02-29) x86_64 GNU/Linux > >> > >>This is old. You should upgrade to something newer, ideally 4.5 but > >>4.4.6 is good also, and then oldest

Re: [RFC] Experimental btrfs encryption

On Mittwoch, 2. März 2016 09:06:57 CET Qu Wenruo wrote: > And maybe I just missed something, but the filename seems not touched, > meaning it will leak a lot of information. > Just like default eCryptfs behavior. > > I understand that's an easy design and it's not a high priority thing, > but I

kworker threads may be working saner now instead of using 100% of a CPU core for minutes (Re: Still not production ready)

On Sonntag, 13. Dezember 2015 23:35:08 CET Martin Steigerwald wrote: > Hi! > > For me it is still not production ready. Again I ran into: > > btrfs kworker thread uses up 100% of a Sandybridge core for minutes on > random write into big file > https://bugzilla.kernel.org/sho

Re: Again, no space left on device while rebalancing and recipe doesnt work

On Samstag, 27. Februar 2016 22:14:50 CET Marc Haber wrote: > Hi, Hi Marc. > I have again the issue of no space left on device while rebalancing > (with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable): > > mh@fan:~$ sudo btrfs balance start /mnt/fanbtr > ERROR: error during balancing

Re: Use fast device only for metadata?

Am Sonntag, 7. Februar 2016, 21:07:13 CET schrieb Kai Krakow: > Am Sun, 07 Feb 2016 11:06:58 -0800 > > schrieb Nikolaus Rath : > > Hello, > > > > I have a large home directory on a spinning disk that I regularly > > synchronize between different computers using unison. That

Re: btrfs-progs and btrfs(8) inconsistencies

Am Donnerstag, 4. Februar 2016, 09:57:54 CET schrieb Moviuro: > > Although personally I like to let all the backward compatibility > > things go hell, but that's definitely not how things work. :( > > > > 2) End-user taste. > > Some end-users like such info as feedback of success. > > Of course

Re: Btrfs Check - "type mismatch with chunk"

Am Dienstag, 5. Januar 2016, 15:34:35 CET schrieb Duncan: > Christoph Anton Mitterer posted on Sat, 02 Jan 2016 06:12:46 +0100 as > > excerpted: > > On Fri, 2015-12-25 at 08:06 +, Duncan wrote: > >> I wasn't personally sure if 4.1 itself was affected or not, but the > >> wiki says don't use

Re: btrfs scrub failing

ohn > > Sent from my iPhone > > > On Jan 3, 2016, at 5:06 AM, Martin Steigerwald <mar...@lichtvoll.de> > > wrote: > > > > Am Sonntag, 3. Januar 2016, 02:02:12 CET schrieb John Center: > >> Hi Martin & Duncan, > > > > Hi John, > &g

Re: btrfs scrub failing

Am Samstag, 2. Januar 2016, 18:27:16 CET schrieb John Center: > Hi Martin, > > > On Jan 2, 2016, at 6:41 AM, Martin Steigerwald <mar...@lichtvoll.de> > > wrote: > > Am Samstag, 2. Januar 2016, 11:35:51 CET schrieb Martin Steigerwald: > >> Am Freitag, 1.

Re: btrfs scrub failing

Am Sonntag, 3. Januar 2016, 02:02:12 CET schrieb John Center: > Hi Martin & Duncan, Hi John, > Since I had a backup of my data, I first ran "btrfs check -p" on the > unmounted array. It first found 3 parent transid errors: > > root@ubuntu:~# btrfs check -p /dev/md126p2 > Checking filesystem on

Re: Unrecoverable fs corruption?

Am Sonntag, 3. Januar 2016, 15:53:56 CET schrieben Sie: > [1] Fat-fingering a deletion: My own brown-bag "I became an admin that > day" case was running a script, unfortunately as root, that I was > debugging, where I did an rm -rf $somevar/*, with $somevar assigned > earlier, only either the

Re: btrfs scrub failing

Am Freitag, 1. Januar 2016, 20:04:43 CET schrieb John Center: > Hi Duncan, > > On Fri, Jan 1, 2016 at 12:05 PM, Duncan <1i5t5.dun...@cox.net> wrote: > > John Center posted on Fri, 01 Jan 2016 11:41:20 -0500 as excerpted: > >> If this doesn't resolve the problem, what would you recommend my next >

Re: [PATCH] BTRFS: Adds the files and options needed for Hybrid Storage

Hello, Am Freitag, 1. Januar 2016, 22:08:32 CET schrieb Sanidhya Solanki: > This patch adds the file required for Hybrid Storage. It contains > the memory, time and size limits for the cache and the statistics that > will be provided while the cache is operating. > It also adds the Makefile

Re: btrfs scrub failing

Am Samstag, 2. Januar 2016, 11:35:51 CET schrieb Martin Steigerwald: > Am Freitag, 1. Januar 2016, 20:04:43 CET schrieb John Center: > > Hi Duncan, > > > > On Fri, Jan 1, 2016 at 12:05 PM, Duncan <1i5t5.dun...@cox.net> wrote: > > > John Center poste

Re: Btrfs Check - "type mismatch with chunk"

Am Donnerstag, 24. Dezember 2015, 23:41:06 CET schrieb Duncan: > Zach Fuller posted on Thu, 24 Dec 2015 13:15:22 -0600 as excerpted: > > I am currently running btrfs on a 2TB GPT drive. The drive is working > > fine, still mounts correctly, and I have experienced no data corruption. > > Whenever I

Re: btrfs scrub failing

Am Freitag, 1. Januar 2016, 13:20:49 CET schrieb John Center: > > On Jan 1, 2016, at 12:41 PM, Martin Steigerwald <mar...@lichtvoll.de> > > wrote: > > Am Freitag, 1. Januar 2016, 11:41:20 CET schrieb John Center: […] > >>> On Jan 1, 2016, at 12:55 AM,

still kworker at 100% cpu in all of device size allocated with chunks situations with write load

0:08:16AM +0800, Qu Wenruo wrote: > >> Martin Steigerwald wrote on 2015/12/13 23:35 +0100: > >>> Hi! > >>> > >>> For me it is still not production ready. > >> > >> Yes, this is the *FACT* and not everyone has a good reason to deny it. >

Re: btrfs scrub failing

Am Freitag, 1. Januar 2016, 11:41:20 CET schrieb John Center: Happy New Year! > > On Jan 1, 2016, at 12:55 AM, Duncan <1i5t5.dun...@cox.net> wrote: > > > > > > John Center posted on Thu, 31 Dec 2015 11:20:28 -0500 as excerpted: > > > > > >> I run a weekly scrub, using Marc Merlin's btrfs-scrub

Re: btrfs und lvm-cache?

Am Mittwoch, 23. Dezember 2015, 11:45:28 CET schrieb Neuer User: > Hello Hi. > I want to setup a small homeserver, based on a HP Microserver Gen8 (4GB > RAM, 2x3TB HDD + 1x120GB SSD) and Proxmox as distro. > > The server will be used to host a (small) number of virtual machines, > most of them

Re: [4.3-rc4] scrubbing aborts before finishing (SOLVED)

Am Mittwoch, 16. Dezember 2015, 00:18:53 CET schrieb Martin Steigerwald: > Am Montag, 14. Dezember 2015, 08:59:59 CET schrieb Martin Steigerwald: > > Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie: > > > Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steig

Re: Still not production ready

Am Dienstag, 15. Dezember 2015, 16:59:58 CET schrieb Chris Mason: > On Mon, Dec 14, 2015 at 10:08:16AM +0800, Qu Wenruo wrote: > > Martin Steigerwald wrote on 2015/12/13 23:35 +0100: > > >Hi! > > > > > >For me it is still not production ready. > > > &

Re: [4.3-rc4] scrubbing aborts before finishing (probably solved)

Am Montag, 14. Dezember 2015, 08:59:59 CET schrieb Martin Steigerwald: > Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie: > > Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald: > > > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Stei

safety of journal based fs (was: Re: still kworker at 100% cpu…)

Qu Wenruo: > Martin Steigerwald wrote on 2015/12/14 09:18 +0100: > > Am Montag, 14. Dezember 2015, 10:08:16 CET schrieb Qu Wenruo: > >> Martin Steigerwald wrote on 2015/12/13 23:35 +0100: […] > >>> I am seriously consider to switch to XFS for my production laptop agai

still kworker at 100% cpu in all of device size allocated with chunks situations with write load (was: Re: Still not production ready)

Am Sonntag, 13. Dezember 2015, 15:19:14 CET schrieb Marc MERLIN: > On Sun, Dec 13, 2015 at 11:35:08PM +0100, Martin Steigerwald wrote: > > Hi! > > > > For me it is still not production ready. Again I ran into: > > > > btrfs kworker thread uses up 100%

Re: [4.3-rc4] scrubbing aborts before finishing

Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie: > Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald: > > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald: > > > I get this: > > > > > > merkaba:~> btr

still kworker at 100% cpu in all of device size allocated with chunks situations with write load (was: Re: Still not production ready)

Am Montag, 14. Dezember 2015, 10:08:16 CET schrieb Qu Wenruo: > Martin Steigerwald wrote on 2015/12/13 23:35 +0100: > > Hi! > > > > For me it is still not production ready. > > Yes, this is the *FACT* and not everyone has a good reason to deny it. > > > Agai

Re: still kworker at 100% cpu in all of device size allocated with chunks situations with write load

Hi Qu. I reply to the journal fs things in a mail with a different subject. Am Montag, 14. Dezember 2015, 16:48:58 CET schrieb Qu Wenruo: > Martin Steigerwald wrote on 2015/12/14 09:18 +0100: > > Am Montag, 14. Dezember 2015, 10:08:16 CET schrieb Qu Wenruo: > >> Martin Steiger

Still not production ready

Hi! For me it is still not production ready. Again I ran into: btrfs kworker thread uses up 100% of a Sandybridge core for minutes on random write into big file https://bugzilla.kernel.org/show_bug.cgi?id=90401 No matter whether SLES 12 uses it as default for root, no matter whether Fujitsu

Re: shall distros run btrfsck on boot?

Am Mittwoch, 25. November 2015, 07:32:34 CET schrieb Austin S Hemmelgarn: > On 2015-11-24 17:26, Eric Sandeen wrote: > > On 11/24/15 2:38 PM, Austin S Hemmelgarn wrote: > >> if the system was > >> shut down cleanly, you're fine barring software bugs, but if it > >> crashed, you should be running a

Re: [4.3-rc4] scrubbing aborts before finishing

Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald: > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald: > > I get this: > > > > merkaba:~> btrfs scrub status -d / > > scrub status for […] > > scrub device /d

Re: [RFC][PATCH 00/12] Enhanced file stat system call

Am Dienstag, 24. November 2015, 00:13:08 CET schrieb Christoph Hellwig: > On Fri, Nov 20, 2015 at 05:19:31PM +0100, Martin Steigerwald wrote: > > I know its mostly relevant for just for FAT32, but on any account rather > > than trying to write 4 GiB and then file, it would be

Unclear error message when running btrfs check on a mountpoint

Hi! With kernel 4.3-rc7 and btrfs-progs 4.2.2 I get: merkaba:~> btrfs check /daten Superblock bytenr is larger than device size Couldn't open file system It took me a moment to see that I used a mountpoint and that this may be the reason for the error message. Maybe check for a device file as

Re: behavior of BTRFS in relation to inodes when moving/copying files between filesystems

Am Dienstag, 13. Oktober 2015, 12:39:12 CET schrieben Sie: > Hi! > > With BTRFS to XFS/Ext4 the inode number of the target file stays the same in > with both cp and mv case (/mnt/zeit is a freshly created XFS in this example): > > merkaba:~> ls -li foo /mnt/zeit/moo > 6609270 foo > 99

Re: [4.3-rc4] scrubbing aborts before finishing

Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald: > I get this: > > merkaba:~> btrfs scrub status -d / > scrub status for […] > scrub device /dev/mapper/sata-debian (id 1) history > scrub started at Thu Oct 22 10:05:49 2015 and was abor

  1   2   3   4   5   >