Forgot to mention that these btrfs partitions reside on an LVM.
2014-05-11 7:56 GMT+02:00 Ronald :
> Dear btrfs developers,
>
> Since v3.14, it has occasionally hapenned that reading some files from
> a btrfs partition cause the process to hang. Right, a file has been
> located that exhibits this
Dear btrfs developers,
Since v3.14, it has occasionally hapenned that reading some files from
a btrfs partition cause the process to hang. Right, a file has been
located that exhibits this behaviour.
/home/gebruiker/.wine_office/drive_c/MSOCache/All
Users/{9012-0030---000FF1CE}-C/
One of the problems with ReiserFS was that a fsck --rebuild-tree would look
through all the disk contents for blocks that appeared to be metadata. A
hostile user could create a file in their home directory (or /tmp or anywhere
else) that contained ReiserFS metadata which would be linked into the
On May 10, 2014, at 7:51 PM, Chris Murphy wrote:
> kernel 3.15.0-0.rc5.git0.1.fc21.x86_64
> btrfs-progs 3.14
>
> /dev/sdb2 = existing btrfs fs
> /dev/sdc3 = unformatted partition
>
>
> # btrfstune -S1 /dev/sdb2
> # mount /dev/sdb2 /mnt
> mount: /dev/sdb2 is write-protected, mounting read-only
Marc MERLIN posted on Sat, 10 May 2014 16:57:18 -0700 as excerpted:
> So, does scrub actually make sure everything on my filesystem is sane,
> or can it miss some kinds of corruptions?
Catching it here as well as the other thread...
All scrub does is verify the checksum (and replace bad versions
Chris Murphy posted on Sat, 10 May 2014 10:49:07 -0600 as excerpted:
> On May 8, 2014, at 7:06 AM, Chris Korent wrote:
>
>> Linux sysresccd 3.10.35-std420-amd64 #2 SMP Wed Apr 2 18:31:51 UTC
>>
>> btrfs --version Btrfs v3.14.1
>
> I'm uncertain if this is an OK combination. I'm under the impre
On Sat, May 10, 2014 at 04:57:18PM -0700, Marc MERLIN wrote:
> On Sat, May 10, 2014 at 03:42:49PM -0700, Marc MERLIN wrote:
> > I tried with 3.14.3 and it went further, however it died with
> > legolas:/mnt/btrfs_pool2# btrfs send home_ro.20140507_10:00:01 | btrfs
> > receive /mnt/btrfs_pool1/
>
Marc MERLIN posted on Fri, 09 May 2014 20:40:26 -0700 as excerpted:
> On May 10, 2014 10:09 AM, "Hugo Mills" wrote:
>>As in, "Your filesystem got corruption as a result of a bug in some
>> earlier version. Upgrading to the new version isn't magically going to
>> make that corruption go away".
Summary is, existing btrfs fs is made into a seed device, mounting it mounts
read-only, add device to it, unmount, then mount again so it mounts rw, then
delete the seed device. I expect that everything on the seed device is moved to
the newly added device, while the seed device is unchanged (to
On Sat, May 10, 2014 at 04:57:18PM -0700, Marc MERLIN wrote:
On Fri, May 09, 2014 at 11:39:13AM -0700, Anacron wrote:
/etc/cron.daily/btrfs-scrub:
scrub device /dev/mapper/cryptroot (id 1) done
scrub started at Fri May 9 06:09:14 2014 and finished after 19153
seconds
total byt
kernel 3.15.0-0.rc5.git0.1.fc21.x86_64
btrfs-progs 3.14
/dev/sdb2 = existing btrfs fs
/dev/sdc3 = unformatted partition
# btrfstune -S1 /dev/sdb2
# mount /dev/sdb2 /mnt
mount: /dev/sdb2 is write-protected, mounting read-only
# btrfs device add /dev/sdc3 /mnt
Performing full device TRIM (75.90GiB
On May 10, 2014, at 6:16 PM, Marc MERLIN wrote:
> On Sat, May 10, 2014 at 06:06:46PM -0600, Chris Murphy wrote:
>> I think the issue might be there are still problems and changing code on the
>> receive side (btrfs-progs). The kernel side code responsible for send is
>> probably working correc
On Sat, May 10, 2014 at 06:06:46PM -0600, Chris Murphy wrote:
> I think the issue might be there are still problems and changing code on the
> receive side (btrfs-progs). The kernel side code responsible for send is
> probably working correctly.
Mmmh, good point, I didn't consider that.
Do you t
On May 10, 2014, at 4:42 PM, Marc MERLIN wrote:
> On Sat, May 10, 2014 at 03:07:10PM -0700, Marc MERLIN wrote:
>> Howdy,
>>
>> While moving data back to a brand new btrfs FS I had just created (with
>> 3.14 tools and under 3.15), I got this:
>>
>> legolas:/mnt/btrfs_pool2# for i in tmp_ro.2014
warn of silent corruption?
Reply-To:
In-Reply-To:
<20140510224249.ga15...@merlins.org>
X-Sysadmin: BOFH
X-URL: http://marc.merlins.org/
On Sat, May 10, 2014 at 03:42:49PM -0700, Marc MERLIN wrote:
> I tried with 3.14.3 and it went further, however it died with
> legolas:/mnt/btrfs_pool2# btrfs
On Sat, May 10, 2014 at 03:07:10PM -0700, Marc MERLIN wrote:
> Howdy,
>
> While moving data back to a brand new btrfs FS I had just created (with
> 3.14 tools and under 3.15), I got this:
>
> legolas:/mnt/btrfs_pool2# for i in tmp_ro.20140507_09:00:31
> root_ro.20140507_10:00:20 usr_ro.20140507_
Howdy,
While moving data back to a brand new btrfs FS I had just created (with
3.14 tools and under 3.15), I got this:
legolas:/mnt/btrfs_pool2# for i in tmp_ro.20140507_09:00:31
root_ro.20140507_10:00:20 usr_ro.20140507_09:00:41 var_ro.20140507_09:00:58
home_ro.20140507_10:00:01; do btrfs send
On May 8, 2014, at 7:06 AM, Chris Korent wrote:
> Linux sysresccd 3.10.35-std420-amd64 #2 SMP Wed Apr 2 18:31:51 UTC
>
> btrfs --version
> Btrfs v3.14.1
I'm uncertain if this is an OK combination. I'm under the impression that the
kernel should be the same or newer version than progs. Also ke
On May 10, 2014, at 7:51 AM, Marc MERLIN wrote:
> Note that in my case, I wasn't trying to run linux inside vbox, just to
> start a win7 vm guest on my linux laptop.
> Is that a case that also is known to cause problems?
No, the host experiences no issues, although in my case the host is OS X s
On Thu, May 08, 2014 at 01:06:25PM +, Chris Korent wrote:
> This seemed to happen after a power failure. I rebooted and the FS was
> mounted, but read-only and there were some errors (journalctl not able
> to start. I did not capture all the errors). I rebooted again and then
> it wouldn't moun
On Fri, May 09, 2014 at 07:54:20PM -0600, Chris Murphy wrote:
> However, I have a recent case in VBox guest, with guest additions
> built. That cause the kernel to be tainted G because it's an out
> of tree kernel module for guest additions. I'm getting a bunch of
> Btrfs errors that aren't reprodu
On May 10, 2014 10:09 AM, "Hugo Mills" wrote:
>As in, "Your filesystem got corruption as a result of a bug in some
> earlier version. Upgrading to the new version isn't magically going to
> make that corruption go away". (Not saying that's what's happened
> here, but it's common, and commonly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 10 May 2014 09:26:22 AM Tom Kuther wrote:
> The same thing happened to me just right now. Also on my SSD, also at
> "fs/btrfs/inode.c:4927 btrfs_invalidate_inode", also on 3.14.
Was your kernel tainted in any way at that point?
Not saying it
Marc MERLIN merlins.org> writes:
>
> Details:
> My system didn't crash, but the filesystem went read only, and of course
> couldn't syslog the error.
> Thankfully I was saved by remote syslog which did work:
>
> kernel: [545039.443412] [ cut here ]
> kernel: [545039.4434
On Mon, May 05, 2014 at 11:10:54PM -0700, David Brown wrote:
On Mon, Feb 24, 2014 at 10:36:52PM -0800, Marc MERLIN wrote:
I got this during a btrfs send:
BTRFS error (device dm-2): did not find backref in send_root. inode=22672,
offset=524288, disk_byte=1490517954560 found extent=1490517954560
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Josef,
On Fri, 9 May 2014 01:22:27 PM Josef Bacik wrote:
> Known problem, fixed in 3.15-rc1. Thanks,
Is the fix suitable for -stable too?
All the best,
Chris
- --
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
-BEGIN PGP SIG
26 matches
Mail list logo
