КЛИЕНТСКИЕ БАЗЫ!
Соберем для Вас по интернет базу данных потенциальных клиентов
для Вашего Бизнеса!
Много! Быстро! Недорого!
Узнайте об этом подробнее по
Тел: +79133913837
Viber: +79133913837
Whatsapp: +79133913837
Skype: prodawez389
Email: eteteri...@gmail.com
--
To unsubscribe from this list:
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
* actual result
===
# ./btrfs device ready /dev/sdb foo
#
===
* expecting result
===
# ./btrfs device ready /dev/sdb foo
btrfs device ready: too many arguments
usage: btrfs
The number of arguments which is allowed to pass became wrong
from the following commit.
commit 176aeca9a148c5e29de0 ("btrfs-progs: add getopt stubs where needed")
* actual result
===
# ./btrfs prop get /btrfs label
label=foo
# ./bt
"property" is considered as working without any options
from the following commit.
commit 176aeca9a148 ("btrfs-progs: add getopt stubs where needed")
However, we can pass -t option to this command.
* actual result
==
# ./btrfs prop list -t f /
* actual result
==
# ./btrfs device usage -- -m /btrfs
/dev/sdf1, ID: 1
Device size: 95367.41MiB
Data,single: 2056.00MiB
Metadata,DUP: 2048.00MiB
System,DUP: 16.00MiB
Unallocated: 912
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 4:14 PM, Chris Murphy wrote:
> Reproducible with Not tainted 4.4.5-300.fc23.x86_64. Attached new
> dmesg to bug report, direct link is:
> https://bugzilla.kernel.org/attachment.cgi?id=208951
The warning doesn't happen if enospc_debug mount option is not set. If
set, it alw
Reproducible with Not tainted 4.4.5-300.fc23.x86_64. Attached new
dmesg to bug report, direct link is:
https://bugzilla.kernel.org/attachment.cgi?id=208951
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
This didn't make it to the list, probably because of the attachment,
so dmesg is attached to this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=114541
On Sun, Mar 13, 2016 at 3:37 PM, Chris Murphy wrote:
> Today I saw two warnings during a filtered balance, -dusage=50 -musage=50.
>
> [61425.1
On Sun, Mar 13, 2016 at 2:55 PM, Roman Mamedov wrote:
> On Sun, 13 Mar 2016 14:10:47 -0600
> Chris Murphy wrote:
>
>> I'm going to guess it's a metadata block, and the profile is single.
>> Otherwise, if it were data it'd just be a corrupt file and you'd be
>> told which one is affected. And if m
On Sun, Mar 13, 2016 at 2:50 PM, Marc Haber wrote:
> On Sun, Mar 13, 2016 at 01:43:50PM -0600, Chris Murphy wrote:
>> On Sat, Mar 12, 2016 at 12:57 PM, Marc Haber
>> wrote:
>> > On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>> >> Something is happening with the usage of this file
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, 13 Mar 2016 14:10:47 -0600
Chris Murphy wrote:
> I'm going to guess it's a metadata block, and the profile is single.
> Otherwise, if it were data it'd just be a corrupt file and you'd be
> told which one is affected. And if metadata had more than one copy,
> then it should recover from t
My unfortunate experience with these transid problems is that they (1)
randomly appear without warning and (2) --repair completely destroys
the filesystem. I have right now two separate volumes on two separate
disks reporting that error, and --repair surely destroyed the first
one. I am trying to s
On Sun, Mar 13, 2016 at 01:43:50PM -0600, Chris Murphy wrote:
> On Sat, Mar 12, 2016 at 12:57 PM, Marc Haber
> wrote:
> > On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> >> Something is happening with the usage of this file system that's out
> >> of the ordinary. This is the first
On Sun, Mar 13, 2016 at 11:24 AM, Roman Mamedov wrote:
>
> "Blowing away" a 6TB filesystem just because some block randomly went "bad",
I'm going to guess it's a metadata block, and the profile is single.
Otherwise, if it were data it'd just be a corrupt file and you'd be
told which one is affec
On Sat, Mar 12, 2016 at 12:57 PM, Marc Haber
wrote:
> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>> Something is happening with the usage of this file system that's out
>> of the ordinary. This is the first time I've seen such a large amount
>> of unused metadata allocation. And
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
On Sun, 13 Mar 2016 17:03:54 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> With backups I'd try it, if only for the personal experience value and to
> see what the result was. But that's certainly more intensive "surgery"
> on the filesystem than --repair, and I'd only do it either for tha
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
Roman Mamedov posted on Sun, 13 Mar 2016 14:24:28 +0500 as excerpted:
> With "Errors found in extent allocation tree", I wonder if I should try
> --init-extent-tree next.
With backups I'd try it, if only for the personal experience value and to
see what the result was. But that's certainly more
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
NeilBrown posted on Sun, 13 Mar 2016 22:33:22 +1100 as excerpted:
> On Sun, Mar 13 2016, Qu Wenruo wrote:
>
>> BTW, I am always interested in, why de-duplication can be shorted as
>> 'dedupe'.
>> I didn't see any 'e' in the whole word "DUPlication".
>> Or it's an abbreviation of "DUPlicatE" inst
Signed-off-by: Alexander Fougner
---
Documentation/btrfs-balance.asciidoc | 4 ++--
Documentation/btrfs-device.asciidoc | 2 +-
Documentation/btrfs-filesystem.asciidoc | 10 +-
Documentation/btrfs-inspect-internal.asciidoc | 2 +-
Documentation/btrfs-man5.ascii
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
one:
[9/508]mh@fan:~$ grep -v 'device dm-15' 20160313-fanbtr-btrfs-syslog
Mar 13 11:05:45 fan mh: BEGIN btrfs-balance script
Mar 13 11:05:45 fan mh: btrfs fi df /
Mar 13 11:05:45 fan root: Data, single: total=80.00GiB, used=77.71GiB
Mar 13 11:05:45 fan root: System, single: total=32.00Mi
On Sun, Mar 13 2016, Qu Wenruo wrote:
> Qu Wenruo wrote on 2016/03/12 16:16 +0800:
>>
>>
>> On 03/11/2016 07:43 PM, David Sterba wrote:
>>> On Thu, Mar 10, 2016 at 08:57:12AM +0800, Qu Wenruo wrote:
> The ioctl FIDEDUPERANGE and the tool duperemove both use "dupe".
> It would be nice if we
Nicholas,
On Sat, Mar 12, 2016 at 12:19 AM, Nicholas D Steeves wrote:
> On 10 March 2016 at 06:10, Alex Lyakas wrote:
>> csum_dirty_buffer was issuing a warning in case the extent buffer
>> did not look alright, but was still returning success.
>> Let's return error in this case, and also add an
On Sat, 12 Mar 2016 22:15:24 +0500
Roman Mamedov wrote:
> Seems like it should be safe to run --repair?
Well this is unexpected, I ran --repair, and it did not do anything.
# btrfsck --repair /dev/alpha/lv1
enabling repair mode
Checking filesystem on /dev/alpha/lv1
UUID: 8cf8eff9-fd5a-4b6f-bb85
32 matches
Mail list logo
