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 [266203.73480
On 03/14/2016 01:13 PM, Marc Haber wrote:
This was not asked, and I didn't try. Since this is an encrypted root
filesystem, is it a workable way to add clear_cache to /etc/fstab,
rebuild initramfs and reboot? Or do you recommend using a rescue system?
You should be able to boot to single user
On Tue, Mar 15, 2016 at 2:42 PM, Marc Haber wrote:
> On Tue, Mar 15, 2016 at 02:29:32PM +0100, Marc Haber wrote:
>> After umounting and btrfs check the block device, things seem to be
>> fine now
>
> But, umounting the btrfs seemed to trigger the following kernel traces:
>
> Mar 15 14:21:30 fan ke
On Tue, Mar 15, 2016 at 09:54:06AM -0400, Austin S. Hemmelgarn wrote:
> On 2016-03-15 09:46, Marc Haber wrote:
> >On Tue, Mar 15, 2016 at 11:52:30AM +0100, Holger Hoffstätte wrote:
> >>On 03/14/16 21:13, Marc Haber wrote:
> >>>Do I need to wait for clear_cache to finish, like until I see disk
> >>>
On 2016-03-15 09:46, Marc Haber wrote:
On Tue, Mar 15, 2016 at 11:52:30AM +0100, Holger Hoffstätte wrote:
On 03/14/16 21:13, Marc Haber wrote:
Do I need to wait for clear_cache to finish, like until I see disk
usage dropping?
The cache isn't that big, so you won't see a huge drop. Just use th
On Tue, Mar 15, 2016 at 11:52:30AM +0100, Holger Hoffstätte wrote:
> On 03/14/16 21:13, Marc Haber wrote:
> > Do I need to wait for clear_cache to finish, like until I see disk
> > usage dropping?
>
> The cache isn't that big, so you won't see a huge drop. Just use the
> disk normally for a few mi
On Tue, Mar 15, 2016 at 02:29:32PM +0100, Marc Haber wrote:
> After umounting and btrfs check the block device, things seem to be
> fine now
But, umounting the btrfs seemed to trigger the following kernel traces:
Mar 15 14:21:30 fan kernel: [92308.377104] [ cut here ]
Mar
On Mon, Mar 14, 2016 at 09:05:46PM +0100, Marc Haber wrote:
> [10/509]mh@fan:~$ sudo btrfs check /media/tempdisk/
> Superblock bytenr is larger than device size
> Couldn't open file system
> [11/509]mh@fan:~$
After umounting and btrfs check the block device, things seem to be
fine now:
[34/532]mh
On Tue, Mar 15, 2016 at 01:15:33PM +0100, Henk Slager wrote:
> On Tue, Mar 15, 2016 at 8:16 AM, Marc Haber
> wrote:
> > On Tue, Mar 15, 2016 at 12:22:00AM +0100, Henk Slager wrote:
> >> The other question is: What is mounted on /media/tempdisk/ ?
> >
> > The "old" btrfs filesystem "ofanbtr", for
On Tue, Mar 15, 2016 at 8:16 AM, Marc Haber wrote:
> On Tue, Mar 15, 2016 at 12:22:00AM +0100, Henk Slager wrote:
>> The other question is: What is mounted on /media/tempdisk/ ?
>
> The "old" btrfs filesystem "ofanbtr", formerly 417 GB in size, now
> resized to 300 GB. Does it need to be umounted
On 03/14/16 21:13, Marc Haber wrote:
> On Mon, Mar 14, 2016 at 01:48:18PM +0100, Holger Hoffstätte wrote:
>> did you ever try to clear the free-space cache via -o clear_cache
>> on mount?
>
> This was not asked, and I didn't try. Since this is an encrypted root
> filesystem, is it a workable way t
On Mon, Mar 14, 2016 at 01:00:13AM +0100, Henk Slager wrote:
> On Sun, Mar 13, 2016 at 9:56 PM, Marc Haber
> wrote:
> > Yes, I want to keep the possibility to remove huge files from
> > snapshots that shouldnt have been on a snapshotted volume in the first
> > place without having to ditch the en
On Tue, Mar 15, 2016 at 12:22:00AM +0100, Henk Slager wrote:
> The other question is: What is mounted on /media/tempdisk/ ?
The "old" btrfs filesystem "ofanbtr", formerly 417 GB in size, now
resized to 300 GB. Does it need to be umounted to be checked?
> At least I think a check of the current 2
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
> >> [266203.734804] BTRFS info (device loop0): disk space caching is enabled
> >>
On Mon, Mar 14, 2016 at 10:59 PM, Chris Murphy wrote:
> I'm a little mystified how btrfs check reports a problem with the
> superblock, and yet this filesystem can still be mounted and used? If
> it mounts rw then resize is possible but why would it be wrong in the
> first place?
Yes you are righ
I'm a little mystified how btrfs check reports a problem with the
superblock, and yet this filesystem can still be mounted and used? If
it mounts rw then resize is possible but why would it be wrong in the
first place?
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linu
>> BTW, I restored and mounted your 20160307-fanbtr-image:
>>
>> [266169.207952] BTRFS: device label fanbtr devid 1 transid 22215732
>> /dev/loop0
>> [266203.734804] BTRFS info (device loop0): disk space caching is enabled
>> [266203.734806] BTRFS: has skinny extents
>> [266204.022175] BTRFS: chec
On Mon, Mar 14, 2016 at 01:48:18PM +0100, Holger Hoffstätte wrote:
> On 03/14/16 13:07, Marc Haber wrote:
> >> And btrfs balance runs into the same ENOSPC issues as the old one:
> >
> > ... with Qu's patch, I now get a reproducible kernel trace:
>
>
>
> That is interesting and useful. Sorry if
Hi Henk,
On Mon, Mar 14, 2016 at 02:46:54PM +0100, Henk Slager wrote:
> On Mon, Mar 14, 2016 at 1:07 PM, Marc Haber
> wrote:
> > Mar 14 10:23:49 fan mh: BEGIN btrfs-balance script
> > Mar 14 10:23:49 fan mh: btrfs fi df /
> > Mar 14 10:23:49 fan root: Data, single: total=79.00GiB, used=78.42GiB
On Mon, Mar 14, 2016 at 1:07 PM, Marc Haber wrote:
> On Sun, Mar 13, 2016 at 12:58:09PM +0100, Marc Haber wrote:
>> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>> > The alternative if this can't be fixed, is to recreate the filesystem
>> > because there's no practical way yet to
On 03/14/16 13:07, Marc Haber wrote:
>> And btrfs balance runs into the same ENOSPC issues as the old one:
>
> ... with Qu's patch, I now get a reproducible kernel trace:
That is interesting and useful. Sorry if this was asked before, but
did you ever try to clear the free-space cache via -o cl
On Sun, Mar 13, 2016 at 12:58:09PM +0100, Marc Haber wrote:
> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> > The alternative if this can't be fixed, is to recreate the filesystem
> > because there's no practical way yet to migrate so many snapshots to a
> > new file system.
>
>
On Mon, Mar 14, 2016 at 01:05:39AM +, Duncan wrote:
> But according to the mkfs.btrfs manpage, the detection is based on
> /sys/block/DEV/queue/rotational (with DEV substituted appropriately), and
> various layers got support for correctly passing that thru at various
> times, some before bt
Marc Haber posted on Sun, 13 Mar 2016 22:05:37 +0100 as excerpted:
> On Sun, Mar 13, 2016 at 05:12:35PM +, Duncan wrote:
>> Marc Haber posted on Sun, 13 Mar 2016 12:58:10 +0100 as excerpted:
>> > I see the same metadata spread as with the old filesystem in btrfs fi
>> > df,
>> > totl at 23 and
On Sun, Mar 13, 2016 at 9:56 PM, Marc Haber wrote:
> On Sun, Mar 13, 2016 at 08:14:45PM +0100, Henk Slager wrote:
>> On Sun, Mar 13, 2016 at 12:58 PM, Marc Haber
>> wrote:
>> > Hi,
>> >
>> > On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>> >> The alternative if this can't be fixed
On Sun, Mar 13, 2016 at 05:12:35PM +, Duncan wrote:
> Marc Haber posted on Sun, 13 Mar 2016 12:58:10 +0100 as excerpted:
> > I see the same metadata spread as with the old filesystem in btrfs fi
> > df,
> > totl at 23 and used at 2.38 GiB. What I find strange is that this
> > filesystem has Dat
On Sun, Mar 13, 2016 at 08:14:45PM +0100, Henk Slager wrote:
> On Sun, Mar 13, 2016 at 12:58 PM, Marc Haber
> wrote:
> > Hi,
> >
> > On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> >> The alternative if this can't be fixed, is to recreate the filesystem
> >> because there's no prac
On Sun, Mar 13, 2016 at 8:14 PM, Henk Slager wrote:
> On Sun, Mar 13, 2016 at 12:58 PM, Marc Haber
> wrote:
>> Hi,
>>
>> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>>> The alternative if this can't be fixed, is to recreate the filesystem
>>> because there's no practical way yet
On Sun, Mar 13, 2016 at 12:58 PM, Marc Haber
wrote:
> Hi,
>
> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>> The alternative if this can't be fixed, is to recreate the filesystem
>> because there's no practical way yet to migrate so many snapshots to a
>> new file system.
>
> I r
Marc Haber posted on Sun, 13 Mar 2016 12:58:10 +0100 as excerpted:
> I see the same metadata spread as with the old filesystem in btrfs fi
> df,
> totl at 23 and used at 2.38 GiB. What I find strange is that this
> filesystem has Data, System and Metadata in "single" profile, is this
> the new def
On Mon, Mar 14, 2016 at 12:17:24AM +1100, Andrew Vaughan wrote:
> On 13 March 2016 at 22:58, Marc Haber wrote:
> > Hi,
> >
> > On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> >> The alternative if this can't be fixed, is to recreate the filesystem
> >> because there's no practical
Hi Marc
On 13 March 2016 at 22:58, Marc Haber wrote:
> Hi,
>
> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>> The alternative if this can't be fixed, is to recreate the filesystem
>> because there's no practical way yet to migrate so many snapshots to a
>> new file system.
>
> I
Hi,
On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> The alternative if this can't be fixed, is to recreate the filesystem
> because there's no practical way yet to migrate so many snapshots to a
> new file system.
I recreated the file system on March 7, with 200 GiB in size, using
33 matches
Mail list logo
