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

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

[4.3-rc4] scrubbing aborts before finishing

Hi! 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 aborted after 00:00:00 total bytes scrubbed: 0.00B with 0 errors scrub device /dev/dm-2 (id 2) histo

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

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 /mnt/zeit/moo merkaba:~> cp foo /mnt/zeit/moo merkaba:~> ls -li foo /mnt/zeit/

Re: FYIO: A rant about btrfs

Am Mittwoch, 16. September 2015, 23:29:30 CEST schrieb Hugo Mills: > > but even then having write-barriers > > turned off is still not as safe as having them turned on. Most of > > the time when I've tried testing with 'nobarrier' (not just on BTRFS > > but on ext* as well), I had just as many iss

Re: RAID1: system stability

Am Mittwoch, 5. August 2015, 13:32:41 schrieb Austin S Hemmelgarn: > On 2015-07-22 07:00, Russell Coker wrote: > > On Tue, 23 Jun 2015 02:52:43 AM Chris Murphy wrote: > >> OK I actually don't know what the intended block layer behavior is > >> when unplugging a device, if it is supposed to vanish,

Re: Defrag operations sometimes don't work.

Am Samstag, 11. Juli 2015, 10:40:29 schrieb erp...@gmail.com: > On Sat, Jul 11, 2015 at 4:12 AM, Martin Steigerwald wrote: > > Always do "sync" after a "btrfs fi defrag" and before measuring with > > "filefrag". The kernel may not have written everyth

Re: Defrag operations sometimes don't work.

Am Freitag, 10. Juli 2015, 19:12:34 schrieb erp...@gmail.com: > Good afternoon, Hi Eric, > First, my apologies if this is a repeat email. My original email > contained an uncompressed copy of dmesg's output and I *believe* > that pushed the message over the 100KB limit, causing the list to > drop

Anyone tried out btrbk yet?

Hi! I see Alex, the developer of btrbk posted here once about btrfs send and receive, but well any other users of btrbk¹? What are your experiences? I consider switching to it from my home grown rsync based backup script to it. Well I may try it for one of my BTRFS volumes in addition to the r

Re: Any hope of pool recovery?

On Friday 03 July 2015 09:31:03 Duncan wrote: > Donald Pearson posted on Thu, 02 Jul 2015 13:19:41 -0500 as excerpted: > > btrfs restore complains that every device is missing except the one that > > you specify on executing the command. Multiple devices as a parameter > > isn't an option. Specif

Re: Btrfs progs release 4.1

Wow, nice collection of changes! Am Montag, 22. Juni 2015, 17:00:23 schrieb David Sterba: > * new > - rescure zero-log > - btrfsune: > - rewrite uuid on a filesystem image > - new option to turn on NO_HOLES incompat feature Did you think about folding btrfstune into btrfs command as w

Re: Stability of Btrfs in Kernel 3.0

Am Donnerstag, 4. Juni 2015, 14:54:48 schrieb Maximilian Eschenbacher: > Greetings, > > I am wondering about the stability of btrfs in this kernel version since > Negear ist selling those ReadyNAS with a buttload of features including > btrfs and linux kernel 3.0. > > Is this a system one can use

[BUG] [4.1-rc4] hung tasks on resume

Hi! I had another BTRFS hang¹. It may be related to the kworker at 100% on write issue that still happened with 4.0 kernels² as / device was 100% allocated and it seems that bug doesn´t happen if there is still device space left to be allocated for chunks. But this time it was on resume from h

Re: The FAQ on fsync/O_SYNC

Am Sonntag, 19. April 2015, 18:18:24 schrieb Hugo Mills: > On Sun, Apr 19, 2015 at 07:50:32PM +0200, Martin Steigerwald wrote: > > Am Sonntag, 19. April 2015, 15:18:51 schrieb Hugo Mills: > > > On Sun, Apr 19, 2015 at 05:10:30PM +0200, Martin Steigerwald wrote: > > > &

Re: The FAQ on fsync/O_SYNC

Am Sonntag, 19. April 2015, 15:18:51 schrieb Hugo Mills: > On Sun, Apr 19, 2015 at 05:10:30PM +0200, Martin Steigerwald wrote: > > Am Sonntag, 19. April 2015, 22:31:02 schrieb Craig Ringer: > > > On 19 April 2015 at 22:28, Martin Steigerwald > > > > wrote: > >

Re: The FAQ on fsync/O_SYNC

Am Sonntag, 19. April 2015, 22:31:02 schrieb Craig Ringer: > On 19 April 2015 at 22:28, Martin Steigerwald wrote: > > Am Sonntag, 19. April 2015, 21:20:11 schrieb Craig Ringer: > >> Hi all > > > > Hi Craig, > > > >> I'm looking into th

Re: The FAQ on fsync/O_SYNC

Am Sonntag, 19. April 2015, 21:20:11 schrieb Craig Ringer: > Hi all Hi Craig, > I'm looking into the advisability of running PostgreSQL on BTRFS, and > after looking at the FAQ there's something I'm hoping you could > clarify. > > The wiki FAQ says: > > "Btrfs does not force all dirty data to d

Re: incremental full file backups to smaller mediums possible?

Am Samstag, 18. April 2015, 01:03:23 schrieb Christoph Anton Mitterer: > On Thu, 2015-04-09 at 16:33 +, Hugo Mills wrote: > >btrfs sub find-new might be more helpful to you here. That will > > > > give you the list of changed files; then just feed that list to your > > existing bin-packing

Re: how to clone a btrfs filesystem

Am Samstag, 18. April 2015, 01:08:44 schrieb Christoph Anton Mitterer: > Hey. Hi Christoph, > I've seen that this has been asked some times before, and there are > stackoverflow/etc. questions on that, but none with a really good > answer. > > How can I best copy one btrfs filesystem (with snaps

[4.0] BTRFS + ecryptfs: Iceweasel cache process hanging on evicting inodes

Hi! This may or may not be related to Bug 90401 - 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 BTRFS free space handling still needs more work: Hangs again Martin Steigerwald | 26 Dec 14:37

Re: number of hardlinks for directory in ls -lid always 1?

ed, Mar 18, 2015 at 03:23:50PM +0100, Martin Steigerwald wrote: > >> >> It explains that having a correct hardlink number for directory is > >> >> not > >> >> mandatory, but it doesn´t explain why BTRFS always has 1 in there > >> >> instead

Re: number of hardlinks for directory in ls -lid always 1?

Am Mittwoch, 18. März 2015, 14:52:30 schrieb David Sterba: > On Wed, Mar 18, 2015 at 02:31:43PM +0100, Martin Steigerwald wrote: > > Am Dienstag, 17. März 2015, 17:07:17 schrieb David Sterba: > > > On Tue, Mar 17, 2015 at 02:33:30PM +0100, Martin Steigerwald wrote: >

Re: number of hardlinks for directory in ls -lid always 1?

Am Dienstag, 17. März 2015, 17:07:17 schrieb David Sterba: > On Tue, Mar 17, 2015 at 02:33:30PM +0100, Martin Steigerwald wrote: > > On BTRFS I see > > > > martin@merkaba:~> ls -lid /usr/local > > 27138 drwxrwsr-x 1 root staff 62 Aug 15 2014 /usr/local > >

number of hardlinks for directory in ls -lid always 1?

Hi! On BTRFS I see martin@merkaba:~> ls -lid /usr/local 27138 drwxrwsr-x 1 root staff 62 Aug 15 2014 /usr/local martin@merkaba:~> ls -lid /usr/local/. 27138 drwxrwsr-x 1 root staff 62 Aug 15 2014 /usr/local/. martin@merkaba:~> ls -lid /usr/local/bin/.. 27138 drwxrwsr-x 1 root staff 62 Aug 15 2

BTRFS wiki: page about recovery (was: Re: [PATCH 0/7] Allow btrfsck to reset csum of all tree blocks, AKA dangerous mode.)

Am Donnerstag, 5. Februar 2015, 16:45:17 schrieb Qu Wenruo: > Original Message > Subject: Re: [PATCH 0/7] Allow btrfsck to reset csum of all tree blocks, > AKA dangerous mode. > From: Martin Steigerwald > To: Qu Wenruo > Date: 2015年02月05日 16:31 > > >

Re: [PATCH 0/7] Allow btrfsck to reset csum of all tree blocks, AKA dangerous mode.

Am Donnerstag, 5. Februar 2015, 09:35:26 schrieb Qu Wenruo: > Original Message > Subject: Re: [PATCH 0/7] Allow btrfsck to reset csum of all tree blocks, > AKA dangerous mode. > From: Martin Steigerwald > To: Qu Wenruo > Date: 2015年02月04日 17:16 > > &

Re: [PATCH 0/7] Allow btrfsck to reset csum of all tree blocks, AKA dangerous mode.

Am Mittwoch, 4. Februar 2015, 15:16:44 schrieb Qu Wenruo: > Btrfs's metadata csum is a good mechanism, keeping bit error away from > sensitive kernel. But such mechanism will also be too sensitive, like > bit error in csum bytes or low all zero bits in nodeptr. > It's a trade using "error tolerance

Re: RAID1 migrate to bigger disks

Am Samstag, 24. Januar 2015, 15:46:22 schrieb Daniel Pocock: > On 24/01/15 15:36, Hugo Mills wrote: > > On Sat, Jan 24, 2015 at 03:32:44PM +0100, Daniel Pocock wrote: > >> I've got a RAID1 on two 1TB partitions, /dev/sda3 and /dev/sdb3 > >> > >> I'm adding two new disks, they will have bigger part

Re: 3.19-rc5: Bug 91911: [REGRESSION] rm command hangs big time with deleting a lot of files at once

Am Freitag, 23. Januar 2015, 09:56:54 schrieb Chris Mason: > On Fri, Jan 23, 2015 at 9:38 AM, Holger Hoffstätte > > wrote: > > On Fri, 23 Jan 2015 15:01:28 +0100, Martin Steigerwald wrote: > >> Hi! > >> > >> Anyone seen this? > >> > >

Re: 3.19-rc5: Bug 91911: [REGRESSION] rm command hangs big time with deleting a lot of files at once

Am Freitag, 23. Januar 2015, 18:29:40 schrieb Zygo Blaxell: > On Fri, Jan 23, 2015 at 03:01:28PM +0100, Martin Steigerwald wrote: > > Hi! > > > > Anyone seen this? > > > > Reported as: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=91911 &g

3.19-rc5: Bug 91911: [REGRESSION] rm command hangs big time with deleting a lot of files at once

Hi! Anyone seen this? Reported as: https://bugzilla.kernel.org/show_bug.cgi?id=91911 I just want to get rid of some 127000+ akonadi lost+found files, any delete command I start just gets rid of some thousands and then hangs. merkaba:~> btrfs fi df /home Data, RAID1: total=160.92GiB, used=1

Re: price to pay for nocow file bit?

Am Samstag, 10. Januar 2015, 13:00:23 schrieben Sie: > I have seen this setting before, but I thought, well, logs would be good to > keep. But for the SSD based laptop I will try volatile storage now. I will > see whether I missed a longer history, but I reduced it before anyway to a > 14 day maxi

Re: price to pay for nocow file bit?

Am Donnerstag, 8. Januar 2015, 06:30:59 schrieb Duncan: > FWIW, I'm systemd on btrfs here, but I use syslog-ng for my non-volatile > logs and have Storage=volatile in journald.conf, using journald only for > current-session, where unit status including last-10-messages makes > troubleshooting /s

Re: Autodefrag option with more delay?

Am Samstag, 10. Januar 2015, 11:41:57 schrieb Martin Steigerwald: > Hi! > > On answering to the nocow file bit thread I wondered about the way > autodefrag works. As I saw quite some time ago with a VM image on a 2,5 > inch external eSATA harddisk it kicks in quite quickly and s

Autodefrag option with more delay?

Hi! On answering to the nocow file bit thread I wondered about the way autodefrag works. As I saw quite some time ago with a VM image on a 2,5 inch external eSATA harddisk it kicks in quite quickly and seems to cause a *lot* of additional writes. I wonder about this case: merkaba:/home/martin

Re: price to pay for nocow file bit?

Am Freitag, 9. Januar 2015, 16:52:59 schrieb David Sterba: > On Thu, Jan 08, 2015 at 02:30:36PM +0100, Lennart Poettering wrote: > > On Wed, 07.01.15 15:10, Josef Bacik (jba...@fb.com) wrote: > > > On 01/07/2015 12:43 PM, Lennart Poettering wrote: > > > >Currently, systemd-journald's disk access pa

Re: btrfs_inode_item's otime?

Am Mittwoch, 7. Januar 2015, 06:42:50 schrieb Christoph Hellwig: > On Wed, Jan 07, 2015 at 02:57:35PM +0100, Lennart Poettering wrote: > > Exposig this as xattr sounds great to me too. > > NAK - exposing random stat data as xattr only creates problems. > > Given that we don't seem to be able to g

Re: Regular rebalancing should be unnecessary? (Was: Re: BTRFS free space handling still needs more work: Hangs again)

Am Freitag, 9. Januar 2015, 11:04:32 schrieb Peter Waller: > Apologies to those receiving this twice. > > On 27 December 2014 at 09:30, Hugo Mills wrote: > > Now, since you're seeing lockups when the space on your disks is > > > > all allocated I'd say that's a bug. However, you're the *only* pe

Re: BTRFS free space handling still needs more work: Hangs again (no complete lockups, "just" tasks stuck for some time)

Am Donnerstag, 8. Januar 2015, 05:45:56 schrieben Sie: > Martin Steigerwald posted on Wed, 07 Jan 2015 20:08:50 +0100 as excerpted: > > No BTRFS developers commented yet on this, neither in this thread nor in > > the bug report at kernel.org I made. > > Just a quick gener

Re: BTRFS free space handling still needs more work: Hangs again (no complete lockups, "just" tasks stuck for some time)

Am Dienstag, 6. Januar 2015, 15:03:23 schrieb Zygo Blaxell: > On Mon, Dec 29, 2014 at 10:32:00AM +0100, Martin Steigerwald wrote: > > Am Sonntag, 28. Dezember 2014, 21:07:05 schrieb Zygo Blaxell: > > > On Sat, Dec 27, 2014 at 08:23:59PM +0100, Martin Steigerwald wrote: […] > &

Re: [PATCH V2] Btrfs: really fix trim 0 bytes after a device delete

t work anyway.) > > V2: > - Rebased onto 3.9. (still applies to and works with 3.19-rc2) > - Take range->minlen into account. > > Reported-by: Lutz Euler > Signed-off-by: Lutz Euler Is that the patch you send me for testing? If so, feel free to add: Reporte

Re: [PATCH 2/2] E2fsprogs: add compress and cow support in chattr, lsattr

Am Sonntag, 4. Januar 2015, 12:40:59 schrieb Erkki Seppala: > Lutz Vieweg writes: > > > Maybe "chattr +C" could print a warning if a file > > to change attributes for is > 0 bytes long? > > This may only affect btrfs. The old ext2? ext3? compression patches > were able to compress pre-existing f

How to handle remove media (was: Re: What about not warn on some abort_transaction() case whose reason is known?)

I am cc´ing this to fsdevel as I think how to handle a disconnected usb device may be of broader interest. Well free to drop Cc again in case you see it as only BTRFS specific issue. Am Mittwoch, 31. Dezember 2014, 09:30:49 schrieb Qu Wenruo: > Hi all, Hi Qu, > While surfing the Redhat BZ, a l

Re: Btrfs progs release 3.18

Am Dienstag, 30. Dezember 2014, 17:34:39 schrieb David Sterba: > Hi, Hi David, > let me announce the release of btrfs-progs version 3.18. There are > updates to UI and several enhancements of check/repair. About 100 > commits from 14 contributors, thank you all! > > Tarballs: https://www.kernel.

Re: fstrim not working on one of three BTRFS filesystems

Am Sonntag, 28. Dezember 2014, 17:58:17 schrieb Martin Steigerwald: > Hi! > > After my recent tests with my /home filesystem and the up and downsizing of > it I get: > > > merkaba:~> LANG=C fstrim -v /home > /home: 0 B (0 bytes) trimmed > merkaba:~> LAN

Re: btrfs doesn't format eMMC if previous filesystem is ext4

Am Montag, 29. Dezember 2014, 09:55:13 schrieb Ankur Tank: > Thank you for reply Anand & Matrin, > > Okay I understand the intention now. > I know it's not the forum to address issues related to mkfs commands > But I think, options used should be same across the mkfs.XXX commands. > Another irregu

Re: BTRFS free space handling still needs more work: Hangs again

Am Sonntag, 28. Dezember 2014, 18:04:31 schrieb Patrik Lundquist: > On 28 December 2014 at 13:03, Martin Steigerwald wrote: > > > > BTW, I found that the Oracle blog didn´t work at all for me. I completed > > a cycle of defrag, sdelete -c and VBoxManage compact, [...] and

Re: btrfs doesn't format eMMC if previous filesystem is ext4

Am Montag, 29. Dezember 2014, 07:15:11 schrieb Ankur Tank: > > -Original Message- > > From: Anand Jain [mailto:anand.j...@oracle.com] > > Sent: Monday, December 29, 2014 8:21 AM > > To: Ankur Tank; linux-btrfs@vger.kernel.org > > Subject: Re: btrfs doesn't format eMMC if previous filesyste

Re: BTRFS free space handling still needs more work: Hangs again (no complete lockups, "just" tasks stuck for some time)

Am Sonntag, 28. Dezember 2014, 21:07:05 schrieb Zygo Blaxell: > On Sat, Dec 27, 2014 at 08:23:59PM +0100, Martin Steigerwald wrote: > > My simple test case didn´t trigger it, and I so not have another twice 160 > > GiB available on this SSDs available to try with a copy of my home

Re: BTRFS free space handling still needs more work: Hangs again (further tests, as close as I dare, current idea)

Am Sonntag, 28. Dezember 2014, 14:56:21 schrieb Martin Steigerwald: > Am Sonntag, 28. Dezember 2014, 14:40:32 schrieb Martin Steigerwald: > > Am Sonntag, 28. Dezember 2014, 14:00:19 schrieb Martin Steigerwald: > > > Am Samstag, 27. Dezember 2014, 14:55:58 schrieb

Re: BTRFS free space handling still needs more work: Hangs again

Am Sonntag, 28. Dezember 2014, 16:27:41 schrieb Robert White: > On 12/28/2014 07:42 AM, Martin Steigerwald wrote: > > Am Sonntag, 28. Dezember 2014, 06:52:41 schrieb Robert White: > >> On 12/28/2014 04:07 AM, Martin Steigerwald wrote: > >>> Am Samstag, 27. Dezember

Re: fstrim not working on one of three BTRFS filesystems

Am Montag, 29. Dezember 2014, 02:08:21 schrieb Duncan: > Martin Steigerwald posted on Sun, 28 Dec 2014 17:58:17 +0100 as excerpted: > > > The fstrim on /home returns immediately. It does not even seem to trim > > anything. What could be the cause for that? > > While

fstrim not working on one of three BTRFS filesystems

Hi! After my recent tests with my /home filesystem and the up and downsizing of it I get: merkaba:~> LANG=C fstrim -v /home /home: 0 B (0 bytes) trimmed merkaba:~> LANG=C fstrim -v / /: 24.5 GiB (26257555456 bytes) trimmed merkaba:~> LANG=C fstrim -v /daten /daten: 2.8 GiB (3016101888 bytes)

Re: BTRFS free space handling still needs more work: Hangs again

Am Sonntag, 28. Dezember 2014, 16:42:20 schrieb Martin Steigerwald: > Am Sonntag, 28. Dezember 2014, 06:52:41 schrieb Robert White: > > On 12/28/2014 04:07 AM, Martin Steigerwald wrote: > > > Am Samstag, 27. Dezember 2014, 20:03:09 schrieb Robert White: > > >> Now:

Re: BTRFS free space handling still needs more work: Hangs again

Am Sonntag, 28. Dezember 2014, 06:52:41 schrieb Robert White: > On 12/28/2014 04:07 AM, Martin Steigerwald wrote: > > Am Samstag, 27. Dezember 2014, 20:03:09 schrieb Robert White: > >> Now: > >> > >> The complaining party has verified the minimum, repeatable ca

Re: BTRFS free space handling still needs more work: Hangs again (further tests, as close as I dare, current idea)

Am Sonntag, 28. Dezember 2014, 14:56:21 schrieb Martin Steigerwald: > Am Sonntag, 28. Dezember 2014, 14:40:32 schrieb Martin Steigerwald: > > Am Sonntag, 28. Dezember 2014, 14:00:19 schrieb Martin Steigerwald: > > > Am Samstag, 27. Dezember 2014, 14:55:58 schrieb

Re: BTRFS free space handling still needs more work: Hangs again (further tests, as close as I dare, current idea)

Am Sonntag, 28. Dezember 2014, 14:40:32 schrieb Martin Steigerwald: > Am Sonntag, 28. Dezember 2014, 14:00:19 schrieb Martin Steigerwald: > > Am Samstag, 27. Dezember 2014, 14:55:58 schrieb Martin Steigerwald: > > > Summarized at > > > > > > Bug 90401 - bt

Re: BTRFS free space handling still needs more work: Hangs again (further tests, as close as I dare)

Am Sonntag, 28. Dezember 2014, 14:00:19 schrieb Martin Steigerwald: > Am Samstag, 27. Dezember 2014, 14:55:58 schrieb Martin Steigerwald: > > Summarized at > > > > Bug 90401 - btrfs kworker thread uses up 100% of a Sandybridge core for > > minutes on random wr

Re: BTRFS free space handling still needs more work: Hangs again (further tests)

Am Samstag, 27. Dezember 2014, 14:55:58 schrieb Martin Steigerwald: > Summarized at > > Bug 90401 - 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 > > see below. This

Re: BTRFS free space handling still needs more work: Hangs again

Am Samstag, 27. Dezember 2014, 20:03:09 schrieb Robert White: > Now: > > The complaining party has verified the minimum, repeatable case of > simple file allocation on a very fragmented system and the responding > party and several others have understood and supported the bug. I didn´t yet prov

Re: BTRFS free space handling still needs more work: Hangs again

Am Samstag, 27. Dezember 2014, 20:03:09 schrieb Robert White: > On 12/27/2014 05:01 PM, Bardur Arantsson wrote: > > On 2014-12-28 01:25, Robert White wrote: > >> On 12/27/2014 08:01 AM, Martin Steigerwald wrote: > >>>> From how you write I get the impres

Re: BTRFS free space handling still needs more work: Hangs again

Am Samstag, 27. Dezember 2014, 16:06:13 schrieb Robert White: > > > >> I also don't know what kind of tool you are using, but it might be > >> repeatedly trying and failing to fallocate the file as a single > >> extent or something equally dumb. > > > > Userspace doesn't as far as I know, get t

Re: BTRFS free space handling still needs more work: Hangs again (no complete lockups, "just" tasks stuck for some time)

Am Samstag, 27. Dezember 2014, 18:40:17 schrieb Hugo Mills: > On Sat, Dec 27, 2014 at 01:28:46PM -0500, Zygo Blaxell wrote: > > On Sat, Dec 27, 2014 at 09:30:43AM +, Hugo Mills wrote: > > > On Sat, Dec 27, 2014 at 10:01:17AM +0100, Martin Steigerwald wrote: > > >

Re: BTRFS free space handling still needs more work: Hangs again

Am Samstag, 27. Dezember 2014, 18:11:21 schrieb Martin Steigerwald: > Am Samstag, 27. Dezember 2014, 16:26:42 schrieb Hugo Mills: > > On Sat, Dec 27, 2014 at 06:54:33AM -0800, Robert White wrote: > > > On 12/27/2014 05:55 AM, Martin Steigerwald wrote: > > [snip] > >

Re: BTRFS free space handling still needs more work: Hangs again

Am Samstag, 27. Dezember 2014, 16:26:42 schrieb Hugo Mills: > On Sat, Dec 27, 2014 at 06:54:33AM -0800, Robert White wrote: > > On 12/27/2014 05:55 AM, Martin Steigerwald wrote: > [snip] > > >while fio was just *laying* out the 4 GiB file. Yes, thats 100% system CPU >

Re: BTRFS free space handling still needs more work: Hangs again

Am Samstag, 27. Dezember 2014, 07:14:32 schrieb Robert White: > On 12/27/2014 06:21 AM, Martin Steigerwald wrote: > > Am Samstag, 27. Dezember 2014, 15:14:05 schrieb Martin Steigerwald: > >> Am Samstag, 27. Dezember 2014, 06:00:48 schrieb Robert White: > >>>

Re: BTRFS free space handling still needs more work: Hangs again

Am Samstag, 27. Dezember 2014, 07:14:32 schrieb Robert White: > But yes, if you open a file and scribble all over it when your disk is > full to within the same order of magnitude as the size of the file you > are scribbling on, you will get into a condition where the _application_ > will aggres

Re: BTRFS free space handling still needs more work: Hangs again

Am Samstag, 27. Dezember 2014, 15:14:05 schrieb Martin Steigerwald: > Am Samstag, 27. Dezember 2014, 06:00:48 schrieb Robert White: > > On 12/27/2014 05:16 AM, Martin Steigerwald wrote: > > > It can easily be reproduced without even using Virtualbox, just by a > > >

Re: BTRFS free space handling still needs more work: Hangs again

Am Samstag, 27. Dezember 2014, 06:00:48 schrieb Robert White: > On 12/27/2014 05:16 AM, Martin Steigerwald wrote: > > It can easily be reproduced without even using Virtualbox, just by a nice > > simple fio job. > > TL;DR: If you want a worst-case example of consuming a BT

Re: BTRFS free space handling still needs more work: Hangs again

Am Samstag, 27. Dezember 2014, 05:49:48 schrieb Robert White: > > Anyway, I got it reproduced. And am about to write a lengthy mail about. > > Have fun with that lengthy email, but the devs already know about the > data waste profile of the system. They just don't have a good solution yet. > > P

Re: BTRFS free space handling still needs more work: Hangs again

to reproduce with a freshly creating filesystem. Am Samstag, 27. Dezember 2014, 09:30:43 schrieb Hugo Mills: > On Sat, Dec 27, 2014 at 10:01:17AM +0100, Martin Steigerwald wrote: > > Am Freitag, 26. Dezember 2014, 14:48:38 schrieb Robert White: > > > On 12/26/2014 05:37 AM,

Re: BTRFS free space handling still needs more work: Hangs again

Am Samstag, 27. Dezember 2014, 03:52:56 schrieb Robert White: > > My theory from watching the Windows XP defragmentation case is this: > > > > - For writing into the file BTRFS needs to actually allocate and use free > > space in the current tree allocation, or, as we seem to misunderstood > > fro

Re: BTRFS free space handling still needs more work: Hangs again

Am Samstag, 27. Dezember 2014, 09:30:43 schrieb Hugo Mills: > > > > > > I only see the lockups of BTRFS is the trees *occupy* all space on the > > device. >No, "the trees" occupy 3.29 GiB of your 5 GiB of mirrored metadata > space. What's more, balance does *not* balance the metadata trees. Th

Re: BTRFS free space handling still needs more work: Hangs again

Am Samstag, 27. Dezember 2014, 09:30:43 schrieb Hugo Mills: > On Sat, Dec 27, 2014 at 10:01:17AM +0100, Martin Steigerwald wrote: > > Am Freitag, 26. Dezember 2014, 14:48:38 schrieb Robert White: > > > On 12/26/2014 05:37 AM, Martin Steigerwald wrote: > > > > Hello!

Re: BTRFS free space handling still needs more work: Hangs again

Am Freitag, 26. Dezember 2014, 14:48:38 schrieb Robert White: > On 12/26/2014 05:37 AM, Martin Steigerwald wrote: > > Hello! > > > > First: Have a merry christmas and enjoy a quiet time in these days. > > > > Second: At a time you feel like it, here is a littl

Re: BTRFS free space handling still needs more work: Hangs again

Am Freitag, 26. Dezember 2014, 14:37:36 schrieben Sie: > I have this on 3.18 kernel on Debian Sid with BTRFS Dual SSD RAID with > space_cache, skinny meta data extents – are these a problem? – and > compress=lzo: > > merkaba:~> btrfs fi sh /home > Label: 'home' uuid: b96c4f72-0523-45ac-a401-f7be7

Re: BTRFS free space handling still needs more work: Hangs again

Am Freitag, 26. Dezember 2014, 15:20:42 schrieben Sie: > And I wonder about: > > Martin 'Helios' Steigerwald - http://www.Lichtvoll.de > > GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 > > > > > > 84C7N�r��yb�X��ǧv�^�)޺{.n�+{�n�߲)w*jg����ݢj/���z�ޖ��2 > > > �ޙ&�)ߡ�

Re: BTRFS free space handling still needs more work: Hangs again

Am Freitag, 26. Dezember 2014, 14:37:36 schrieben Sie: > It currently is here: > > merkaba:~> btrfs balance status /home > Balance on '/home' is running > 32 out of about 164 chunks balanced (53 considered), 80% left > > merkaba:~> btrfs fi df /home > Data, RAID1: total=154.97GiB, used=142.10GiB

BTRFS free space handling still needs more work: Hangs again

Hello! First: Have a merry christmas and enjoy a quiet time in these days. Second: At a time you feel like it, here is a little rant, but also a bug report: I have this on 3.18 kernel on Debian Sid with BTRFS Dual SSD RAID with space_cache, skinny meta data extents – a

Re: [PATCH V2][BTRFS-PROGS] Improve output of mkfs.btrfs command

Am Mittwoch, 17. Dezember 2014, 21:14:04 schrieb Goffredo Baroncelli: > # mkfs.btrfs -L btrfs-test -f -M -m raid5 -d raid5 /dev/vd[b-k]" > BTRFS filesystem summary: > Label:btrfs-test > UUID: 4409e381-f066-4e7b-af74-b6525fefa08b > > Node size:4096

Re: Crazy idea of cleanup the inode_record btrfsck things with SQL?

Hi Qu, Am Dienstag, 2. Dezember 2014, 08:37:44 schrieb Qu Wenruo: > Original Message > Subject: Re: Crazy idea of cleanup the inode_record btrfsck things with SQL? > From: Austin S Hemmelgarn > To: Qu Wenruo , linux-btrfs > > Date: 2014年12月01日 20:53 > > > On 2014-11-30 20:58,

Re: Why is the actual disk usage of btrfs considered unknowable?

Am Montag, 8. Dezember 2014, 09:57:50 schrieb Austin S Hemmelgarn: > On 2014-12-08 09:47, Martin Steigerwald wrote: > > Hi, > > > > Am Sonntag, 7. Dezember 2014, 21:32:01 schrieb Robert White: > >> On 12/07/2014 07:40 AM, Martin Steigerwald wrote: > >>>

Re: Why is the actual disk usage of btrfs considered unknowable?

Hi, Am Sonntag, 7. Dezember 2014, 21:32:01 schrieb Robert White: > On 12/07/2014 07:40 AM, Martin Steigerwald wrote: > > Well what would be possible I bet would be a kind of system call like > > this: > > > > I need to write 5 GB of data in 100 of files to /opt/mynew

Re: Why is the actual disk usage of btrfs considered unknowable?

Am Sonntag, 7. Dezember 2014, 18:34:44 schrieb Hugo Mills: > On Sun, Dec 07, 2014 at 10:20:27AM -0800, ashf...@whisperpc.com wrote: > [snip] > > > > 3) From what I gathered it is planned to allow different raid / > > > redundancy levels for different subvolumes. BTRFS can´t know > > > beforehand

Re: Why is the actual disk usage of btrfs considered unknowable?

Am Sonntag, 7. Dezember 2014, 10:20:27 schrieb ashf...@whisperpc.com: > Martin, > > > I read that the actual > > what is free is unknown. And there are several reasons for that: > > > > 1) On a compressed filesystem you cannot know, but only estimate the > > compression ratio for future data. >

Re: Why is the actual disk usage of btrfs considered unknowable?

Am Sonntag, 7. Dezember 2014, 16:33:37 schrieb Martin Steigerwald: > What might be possible but still has the limitation of the fourth point > above, would be a query: How much free space do you have *right* know, on > this directory path, if I write with standard settings. > &g

Re: Why is the actual disk usage of btrfs considered unknowable?

Hi Shriramana! Am Sonntag, 7. Dezember 2014, 20:45:59 schrieb Shriramana Sharma: > IIUC: > > 1) btrfs fi df already shows the alloc-ed space and the space used out of > that. > > 2) Despite snapshots, CoW and compression, the tree knows how many > extents of data and metadata there are, and how

Re: [PATCH 0/4] New 'btrfs chunk list' command

Hi Goffredo, Am Dienstag, 25. November 2014, 16:57:21 schrieb Goffredo Baroncelli: > This is a revamp of a my previous patches set[1]. After more than > year of attempts these patches were never merged, so I tried to > simplify them and to change a bit the focus. The previous patches set > had the

Re: What is the vision for btrfs fs repair?

Am Mittwoch, 8. Oktober 2014, 14:11:51 schrieb Eric Sandeen: > I was looking at Marc's post: > > http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-> > and-Btrfs-Filesystem-Repair.html > > and it feels like there isn't exactly a cohesive, overarching vision for > repair

Re: What is the vision for btrfs fs repair?

Am Freitag, 10. Oktober 2014, 10:37:44 schrieb Chris Murphy: > On Oct 10, 2014, at 6:53 AM, Bob Marley wrote: > > On 10/10/2014 03:58, Chris Murphy wrote: > >>> * mount -o recovery > >>> > >>> "Enable autorecovery attempts if a bad tree root is found at mount > >>> time." > >> > >> I'm confu

Re: What is the vision for btrfs fs repair?

Am Donnerstag, 9. Oktober 2014, 21:58:53 schrieben Sie: > > * btrfs-zero-log > > "remove the log tree if log tree is corrupt" > > * btrfs rescue > > "Recover a damaged btrfs filesystem" > > chunk-recover > > super-recover > > How does this relate to btrfs check? > > *

[REGRESSION?] Used+avail gives more than size of device

Hi! On 3.17, i.e. since the size reporting changes, I get: merkaba:~> LANG=C df -hT -t btrfs Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/sata-debian btrfs 30G 19G 21G 48% / /dev/mapper/sata-debian btrfs 30G 19G 21G 48% /mnt/debian-zeit /dev/mapper/msa

Re: INFO: task btrfs-transacti:2408 blocked for more than 120 seconds.

Am Mittwoch, 3. September 2014, 19:17:17 schrieben Sie: > At a 32 bit stable Gentoo Linux I do have 2 BTRFS file systems : > > $ mount | grep btrfs > /var/lib/portage.fs on /usr/portage type btrfs (rw,noatime,compress=lzo) > /var/lib/pkg.fs on /var/db/pkg type btrfs (rw,noatime,compress=lzo) > >

Re: [PATCH v3] Btrfs: fix task hang under heavy compressed write

Am Dienstag, 26. August 2014, 15:20:21 schrieb Martin Steigerwald: > Am Dienstag, 26. August 2014, 09:02:23 schrieb Chris Mason: > > On 08/26/2014 06:20 AM, Martin Steigerwald wrote: > > > Am Montag, 25. August 2014, 10:58:13 schrieb Chris Mason: > > >> On 08/

Re: 3.17: Yay! New sizes in df -h

Am Mittwoch, 27. August 2014, 10:54:56 schrieb Chris Murphy: > On Aug 27, 2014, at 5:45 AM, Martin Steigerwald wrote: > > Hi! > > > > Now I get this with 3.17-rc2: > > > > merkaba:~> LANG=C df -hT / /home > > Filesystem Type Size Used Avail Use%

3.17: Yay! New sizes in df -h

Hi! Now I get this with 3.17-rc2: merkaba:~> LANG=C df -hT / /home Filesystem Type Size Used Avail Use% Mounted on /dev/dm-5 btrfs 30G 17G 23G 43% / /dev/dm-0 btrfs 160G 129G 59G 69% /home /: 17+23 = 40 GiB, compressed 10 GiB away with lzo? /home: 59+129 = 188 GiB,

Re: BTRFS claims that empty directory is not empty and refuses to delete it

Am Dienstag, 15. Juli 2014, 11:01:25 schrieb Hugo Mills: > On Tue, Jul 15, 2014 at 11:09:53AM +0200, Martin Steigerwald wrote: > > Hello! > > > > This is with 3.16-rc4 – stepped back to this one after having two hangs in > > one day with 3.16-rc5, see other thread sta

Re: [PATCH v3] Btrfs: fix task hang under heavy compressed write

Am Dienstag, 26. August 2014, 09:02:23 schrieb Chris Mason: > On 08/26/2014 06:20 AM, Martin Steigerwald wrote: > > Am Montag, 25. August 2014, 10:58:13 schrieb Chris Mason: > >> On 08/15/2014 11:36 AM, Liu Bo wrote: > >>> This has been reported and discussed

Re: [PATCH v3] Btrfs: fix task hang under heavy compressed write

Am Dienstag, 26. August 2014, 18:38:03 schrieb Liu Bo: > On Tue, Aug 26, 2014 at 12:20:28PM +0200, Martin Steigerwald wrote: > > Am Montag, 25. August 2014, 10:58:13 schrieb Chris Mason: > > > On 08/15/2014 11:36 AM, Liu Bo wrote: > > > > This has been reported and

<    1   2   3   4   5   6   >