Re: How to map extents to files

On Jun 10 2016, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > At 06/02/2016 10:56 PM, Nikolaus Rath wrote: >> On Jun 02 2016, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: >>> At 06/02/2016 11:06 AM, Nikolaus Rath wrote: >>>> Hello, >>>> &

Re: fsck: to repair or not to repair

On Jun 10 2016, Adam Borowski <kilob...@angband.pl> wrote: > On Fri, Jun 10, 2016 at 08:54:36AM -0700, Nikolaus Rath wrote: >> On Jun 10 2016, "Austin S. Hemmelgarn" <ahferro...@gmail.com> wrote: >> > JFYI, if you've using GNU cp, you can pass '--reflink

Re: fsck: to repair or not to repair

On Jun 10 2016, "Austin S. Hemmelgarn" wrote: > JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid > it making reflinks. I would have expected so, but at least in coreutils 8.23 the only valid options are "always" and "auto" (at least according to cp

Re: fsck: to repair or not to repair

On Jun 10 2016, "Austin S. Hemmelgarn" wrote: > JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid > it making reflinks. I would have expected so, but at least in coreutils 8.23 the only valid options are "never" and "auto" (at least according to cp

Re: fsck: to repair or not to repair

On May 11 2016, Nikolaus Rath <nikol...@rath.org> wrote: > Hello, > > I recently ran btrfsck on one of my file systems, and got the following > messages: > > checking extents > checking free space cache > checking fs roots > root 5 inode 3149867 errors 400, nb

Re: How to map extents to files

On Jun 01 2016, Nikolaus Rath <nikol...@rath.org> wrote: > Hello, > > For one of my btrfs volumes, btrfsck reports a lot of the following > warnings: > > [...] > checking extents > bad extent [138477568, 138510336), type mismatch with chunk > bad extent [140

Re: How to map extents to files

On Jun 02 2016, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > At 06/02/2016 11:06 AM, Nikolaus Rath wrote: >> Hello, >> >> For one of my btrfs volumes, btrfsck reports a lot of the following >> warnings: >> >> [...] >> checking extents >> ba

How to map extents to files

Hello, For one of my btrfs volumes, btrfsck reports a lot of the following warnings: [...] checking extents bad extent [138477568, 138510336), type mismatch with chunk bad extent [140091392, 140148736), type mismatch with chunk bad extent [140148736, 140201984), type mismatch with chunk bad

Problems with storing Mercurial repositories

Hello, A little while ago I noticed that a btrfsck of my home directory produced a *lot* of the following errors: [...] checking fs roots root 5 inode 3149867 errors 400, nbytes wrong root 5 inode 3150237 errors 400, nbytes wrong root 5 inode 3150238 errors 400, nbytes wrong [...] I've now

Re: fsck: to repair or not to repair

On May 13 2016, Duncan <1i5t5.dun...@cox.net> wrote: > Because btrfs can be multi-device, it needs some way to track which > devices belong to each filesystem, and it uses filesystem UUID for this > purpose. > > If you clone a filesystem (for instance using dd or lvm snapshotting, > doesn't

Re: Input/output error on newly created file

On May 12 2016, Diego Calleja <dieg...@gmail.com> wrote: > El jueves, 12 de mayo de 2016 8:46:00 (CEST) Nikolaus Rath escribió: >> *ping* >> >> Anyone any idea? > > All I can say is that I've had the same problem in the past. In my > case, the pro

Re: fsck: to repair or not to repair

On May 12 2016, Henk Slager <eye...@gmail.com> wrote: > On Wed, May 11, 2016 at 11:10 PM, Nikolaus Rath <nikol...@rath.org> wrote: >> Hello, >> >> I recently ran btrfsck on one of my file systems, and got the following >> messages: >> >> checking

Re: Input/output error on newly created file

*ping* Anyone any idea? Best, -Nikolaus On May 09 2016, Nikolaus Rath <nikol...@rath.org> wrote: > On May 09 2016, Filipe Manana <fdman...@gmail.com> wrote: >> On Sun, May 8, 2016 at 11:18 PM, Nikolaus Rath <nikol...@rath.org> wrote: >>> Hello, >

fsck: to repair or not to repair

Hello, I recently ran btrfsck on one of my file systems, and got the following messages: checking extents checking free space cache checking fs roots root 5 inode 3149867 errors 400, nbytes wrong root 5 inode 3150237 errors 400, nbytes wrong root 5 inode 3150238 errors 400, nbytes wrong root 5

Re: Input/output error on newly created file

On May 09 2016, Filipe Manana <fdman...@gmail.com> wrote: > On Sun, May 8, 2016 at 11:18 PM, Nikolaus Rath <nikol...@rath.org> wrote: >> Hello, >> >> I just created an innocent 10 MB on a btrfs file system, yet my attempt >> to read it a few seconds later (

Input/output error on newly created file

Hello, I just created an innocent 10 MB on a btrfs file system, yet my attempt to read it a few seconds later (and ever since), just gives: $ ls -l in-progress/mysterious-io-error -rw-rw-r-- 1 nikratio nikratio 10485760 May 8 14:41 in-progress/mysterious-io-error $ cat

Re: Use fast device only for metadata?

On Feb 09 2016, Kai Krakow wrote: > You could even format a bcache superblock "just in case", > and add an SSD later. Without SSD, bcache will just work in passthru > mode. Do the LVM concerns still apply in passthrough mode, or only when there's an actual cache? Thanks,

Re: Use fast device only for metadata?

On Feb 09 2016, Kai Krakow wrote: > I'm myself using bcache+btrfs and it ran bullet proof so far, even > after unintentional resets or power outage. It's important tho to NOT > put any storage layer between bcache and your devices or between btrfs > and your device as there

Re: Use fast device only for metadata?

On Feb 09 2016, Kai Krakow wrote: >> If there's no way to put LVM anywhere into the stack that'd be a >> bummer, I very much want to use dm-crypt (and I guess that counts as >> lvm?). > > Wasn't there plans for integrating per-file encryption into btrfs (like > there's

Re: Use fast device only for metadata?

On Feb 08 2016, Nikolaus Rath <nikol...@rath.org> wrote: > Otherwise I'll give bcache a shot. I've avoided it so far because of the > need to reformat and because of rumours that it doesn't work well with > LVM or BTRFS. But it sounds as if that's not the case.. I now have the

Re: Use fast device only for metadata?

On Feb 07 2016, Martin Steigerwald <mar...@lichtvoll.de> wrote: > Am Sonntag, 7. Februar 2016, 21:07:13 CET schrieb Kai Krakow: >> Am Sun, 07 Feb 2016 11:06:58 -0800 >> >> schrieb Nikolaus Rath <nikol...@rath.org>: >> > Hello, >> > >>

Use fast device only for metadata?

Hello, I have a large home directory on a spinning disk that I regularly synchronize between different computers using unison. That takes ages, even though the amount of changed files is typically small. I suspect most if the time is spend walking through the file system and checking mtimes. So

Re: Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()

On Mar 26 2015, Chris Murphy li...@colorremedies.com wrote: On Thu, Mar 26, 2015 at 6:38 PM, Nikolaus Rath nikol...@rath.org wrote: I'm running 4.0-rc3, and I'm regularly getting these warnings in my kernel log: Mar 26 17:31:13 vostro kernel: [21480.088682] WARNING: CPU: 0 PID: 28958 at fs

Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()

Hello, I'm running 4.0-rc3, and I'm regularly getting these warnings in my kernel log: Mar 26 17:31:13 vostro kernel: [21480.088671] [ cut here ] Mar 26 17:31:13 vostro kernel: [21480.088682] WARNING: CPU: 0 PID: 28958 at fs/btrfs/inode.c:8693

File system stuck in scrub

Hello, I started a scrub of one of my btrfs filesystem and then had to restart the system. `systemctl restart` seemed to terminate all processes, but then got stuck at the end. The disk activity led was still flashing rapidly at that point, so I assume that the active scrub was preventing the

blocked tasks right after mounting (was: Hang when trying to access fs)

Nikolaus Rath nikol...@rath.org writes: Hello, When trying to rsync to btrfs, the process just hangs. dmesg output alternates between: [...] I guess I should also mention that this is reproducible, and I don't even need to run rsync. Simply mounting the file system produces a similar warning

Hang when trying to access fs

Hello, When trying to rsync to btrfs, the process just hangs. dmesg output alternates between: Jan 28 09:42:49 vostro kernel: [ 360.460076] INFO: task rsync:3484 blocked for more than 120 seconds. Jan 28 09:42:49 vostro kernel: [ 360.460079] echo 0 /proc/sys/kernel/hung_task_timeout_secs

Re: blocked tasks right after mounting

Duncan 1i5t5.dun...@cox.net writes: Nikolaus Rath posted on Sat, 28 Jan 2012 10:23:53 -0500 as excerpted: Nikolaus Rath nikol...@rath.org writes: Hello, When trying to rsync to btrfs, the process just hangs. dmesg output alternates between: [...] I guess I should also mention