[ ... ]
>>> $ D='btrfs f2fs gfs2 hfsplus jfs nilfs2 reiserfs udf xfs'
>>> $ find $D -name '*.ko' | xargs size | sed 's/^ *//;s/ .*\t//g'
>>> textfilename
>>> 832719 btrfs/btrfs.ko
>>> 237952 f2fs/f2fs.ko
>>> 251805 gfs2/gfs2.ko
>>> 72731 hfsplus/hfsplus.ko
>>> 171623 j
Am Mon, 27 Mar 2017 20:06:46 +0500
schrieb Roman Mamedov :
> On Mon, 27 Mar 2017 16:49:47 +0200
> Christian Theune wrote:
>
> > Also: the idea of migrating on btrfs also has its downside - the
> > performance of “mkdir” and “fsync” is abysmal at the moment. I’m
> > waiting for the current shrink
Indeed, that does make sense. It's the output of the size command in
the Berkeley format of "text", not decimal, octal or hex. Out of
curiosity about kernel module sizes, I dug up some old MacBooks and
looked around in:
/System/Library/Extensions/[modulename].kext/Content/MacOS:
udf is 637K on
GWB posted on Fri, 31 Mar 2017 19:02:40 -0500 as excerpted:
> It is confusing, and now that I look at it, more than a little funny.
> Your use of xargs returns the size of the kernel module for each of the
> filesystem types. I think I get it now: you are pointing to how large
> the kernel module
It is confusing, and now that I look at it, more than a little funny.
Your use of xargs returns the size of the kernel module for each of
the filesystem types. I think I get it now: you are pointing to how
large the kernel module for btrfs is compared to other file system
kernel modules, 833 megs
> [ ... ] what the signifigance of the xargs size limits of
> btrfs might be. [ ... ] So what does it mean that btrfs has a
> higher xargs size limit than other file systems? [ ... ] Or
> does the lower capacity for argument length for hfsplus
> demonstrate it is the superior file system for avoidi
Well, now I am curious. Until we hear back from Christiane on the
progress of the never ending file system shrinkage, I suppose it can't
hurt to ask what the signifigance of the xargs size limits of btrfs
might be. Or, again, if Christiane is already happily on his way to
an xfs server running ov
>>> My guess is that very complex risky slow operations like
>>> that are provided by "clever" filesystem developers for
>>> "marketing" purposes, to win box-ticking competitions.
>>> That applies to those system developers who do know better;
>>> I suspect that even some filesystem developers are
On 2017-03-30 11:55, Peter Grandi wrote:
My guess is that very complex risky slow operations like that are
provided by "clever" filesystem developers for "marketing" purposes,
to win box-ticking competitions. That applies to those system
developers who do know better; I suspect that even some fil
>> [ ... ] CentOS, Redhat, and Oracle seem to take the position
>> that very large data subvolumes using btrfs should work
>> fine. But I would be curious what the rest of the list thinks
>> about 20 TiB in one volume/subvolume.
> To be sure I'm a biased voice here, as I have multiple
> independen
> Can you try to first dedup the btrfs volume? This is probably
> out of date, but you could try one of these: [ ... ] Yep,
> that's probably a lot of work. [ ... ] My recollection is that
> btrfs handles deduplication differently than zfs, but both of
> them can be very, very slow
But the big de
>>> The way btrfs is designed I'd actually expect shrinking to
>>> be fast in most cases. [ ... ]
>> The proposed "move whole chunks" implementation helps only if
>> there are enough unallocated chunks "below the line". If regular
>> 'balance' is done on the filesystem there will be some, but that
Duncan posted on Fri, 31 Mar 2017 05:26:39 + as excerpted:
> Compare that to the current thread where someone's trying to do a resize
> of a 20+ TB btrfs and it was looking to take a week, due to the massive
> size and the slow speed of balance on his highly reflinked filesystem on
> spinning
GWB posted on Thu, 30 Mar 2017 20:00:22 -0500 as excerpted:
> CentOS, Redhat, and Oracle seem to take the position that very large
> data subvolumes using btrfs should work fine. But I would be curious
> what the rest of the list thinks about 20 TiB in one volume/subvolume.
To be sure I'm a bias
Hello, Christiane,
I very much enjoyed the discussion you sparked with your original
post. My ability in btrfs is very limited, much less than the others
who have replied here, so this may not be much help.
Let us assume that you have been able to shrink the device to the size
you need, and you
> The proposed "move whole chunks" implementation helps only if
> there are enough unallocated chunks "below the line". If regular
> 'balance' is done on the filesystem there will be some, but that
> just spreads the cost of the 'balance' across time, it does not
> by itself make a «risky, difficul
>> My guess is that very complex risky slow operations like that are
>> provided by "clever" filesystem developers for "marketing" purposes,
>> to win box-ticking competitions. That applies to those system
>> developers who do know better; I suspect that even some filesystem
>> developers are "opti
> I’ve glazed over on “Not only that …” … can you make youtube
> video of that :)) [ ... ] It’s because I’m special :*
Well played again, that's a fairly credible impersonation of a
node.js/mongodb developer :-).
> On a real note thank’s [ ... ] to much of open source stuff is
> based on short c
>> As a general consideration, shrinking a large filetree online
>> in-place is an amazingly risky, difficult, slow operation and
>> should be a last desperate resort (as apparently in this case),
>> regardless of the filesystem type, and expecting otherwise is
>> "optimistic".
> The way btrfs is
> As a general consideration, shrinking a large filetree online
> in-place is an amazingly risky, difficult, slow operation and
> should be a last desperate resort (as apparently in this case),
> regardless of the filesystem type, and expecting otherwise is
> "optimistic".
The way btrfs is designe
On 2017-03-28 10:43, Peter Grandi wrote:
This is going to be long because I am writing something detailed
hoping pointlessly that someone in the future will find it by
searching the list archives while doing research before setting
up a new storage system, and they will be the kind of person
that
I’ve glazed over on “Not only that …” … can you make youtube video of that :
> On 28 Mar 2017, at 16:06, Peter Grandi wrote:
>
>> I glazed over at “This is going to be long” … :)
>>> [ ... ]
>
> Not only that, you also top-posted while quoting it pointlessly
> in its entirety, to the whole m
> I glazed over at “This is going to be long” … :)
>> [ ... ]
Not only that, you also top-posted while quoting it pointlessly
in its entirety, to the whole mailing list. Well played :-).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...
> [ ... ] slaps together a large storage system in the cheapest
> and quickest way knowing that while it is mostly empty it will
> seem very fast regardless and therefore to have awesome
> performance, and then the "clever" sysadm disappears surrounded
> by a halo of glory before the storage syste
> [ ... ] reminded of all the cases where someone left me to
> decatastrophize a storage system built on "optimistic"
> assumptions.
In particular when some "clever" sysadm with a "clever" (or
dumb) manager slaps together a large storage system in the
cheapest and quickest way knowing that while i
I glazed over at “This is going to be long” … :)
> On 28 Mar 2017, at 15:43, Peter Grandi wrote:
>
> This is going to be long because I am writing something detailed
> hoping pointlessly that someone in the future will find it by
> searching the list archives while doing research before setting
This is going to be long because I am writing something detailed
hoping pointlessly that someone in the future will find it by
searching the list archives while doing research before setting
up a new storage system, and they will be the kind of person
that tolerates reading messages longer than Twi
On Mon, 27 Mar 2017 16:49:47 +0200
Christian Theune wrote:
> Also: the idea of migrating on btrfs also has its downside - the performance
> of “mkdir” and “fsync” is abysmal at the moment. I’m waiting for the current
> shrinking job to finish but this is likely limited to the “find free space”
Hi,
> On Mar 27, 2017, at 4:48 PM, Roman Mamedov wrote:
>
> On Mon, 27 Mar 2017 15:20:37 +0200
> Christian Theune wrote:
>
>> (Background info: we’re migrating large volumes from btrfs to xfs and can
>> only do this step by step: copying some data, shrinking the btrfs volume,
>> extending the
On Mon, 27 Mar 2017 15:20:37 +0200
Christian Theune wrote:
> (Background info: we’re migrating large volumes from btrfs to xfs and can
> only do this step by step: copying some data, shrinking the btrfs volume,
> extending the xfs volume, rinse repeat. If someone should have any
> suggestions to
Hi,
> On Mar 27, 2017, at 4:17 PM, Austin S. Hemmelgarn
> wrote:
>
> One other thing that I just thought of:
> For a backup system, assuming some reasonable thinning system is used for the
> backups, I would personally migrate things slowly over time by putting new
> backups on the new filesy
On 2017-03-27 09:54, Christian Theune wrote:
Hi,
On Mar 27, 2017, at 3:50 PM, Christian Theune wrote:
Hi,
On Mar 27, 2017, at 3:46 PM, Austin S. Hemmelgarn wrote:
Something I’d like to verify: does having traffic on the volume have
the potential to delay this infinitely? I.e. does the s
On 2017-03-27 09:50, Christian Theune wrote:
Hi,
On Mar 27, 2017, at 3:46 PM, Austin S. Hemmelgarn wrote:
Something I’d like to verify: does having traffic on the volume have
the potential to delay this infinitely? I.e. does the system write
to any segments that we’re trying to free so it m
Hi,
> On Mar 27, 2017, at 3:50 PM, Christian Theune wrote:
>
> Hi,
>
>> On Mar 27, 2017, at 3:46 PM, Austin S. Hemmelgarn
>> wrote:
>>>
Something I’d like to verify: does having traffic on the volume have
the potential to delay this infinitely? I.e. does the system write
to an
Hi,
> On Mar 27, 2017, at 3:46 PM, Austin S. Hemmelgarn
> wrote:
>>
>>> Something I’d like to verify: does having traffic on the volume have
>>> the potential to delay this infinitely? I.e. does the system write
>>> to any segments that we’re trying to free so it may have to work on
>>> the sam
On 2017-03-27 09:24, Hugo Mills wrote:
On Mon, Mar 27, 2017 at 03:20:37PM +0200, Christian Theune wrote:
Hi,
On Mar 27, 2017, at 3:07 PM, Hugo Mills wrote:
On my hardware (consumer HDDs and SATA, RAID-1 over 6 devices), it
takes about a minute to move 1 GiB of data. At that rate, it would
On Mon, Mar 27, 2017 at 03:20:37PM +0200, Christian Theune wrote:
> Hi,
>
> > On Mar 27, 2017, at 3:07 PM, Hugo Mills wrote:
> >
> > On my hardware (consumer HDDs and SATA, RAID-1 over 6 devices), it
> > takes about a minute to move 1 GiB of data. At that rate, it would
> > take 1000 minutes (
Hi,
> On Mar 27, 2017, at 3:07 PM, Hugo Mills wrote:
>
> On my hardware (consumer HDDs and SATA, RAID-1 over 6 devices), it
> takes about a minute to move 1 GiB of data. At that rate, it would
> take 1000 minutes (or about 16 hours) to move 1 TiB of data.
>
> However, there are cases where
On Mon, Mar 27, 2017 at 01:17:26PM +0200, Christian Theune wrote:
> Hi,
>
> I’m currently shrinking a device and it seems that the performance of shrink
> is abysmal. I intended to shrink a ~22TiB filesystem down to 20TiB. This is
> still using LVM underneath so that I can’t just remove a device
> On Mar 27, 2017, at 1:51 PM, Christian Theune wrote:
>
> Hi,
>
> (I hope I’m not double posting. My mail client was misconfigured and I think
> I only managed to send the mail correctly this time.)
Turns out I did double post. Mea culpa.
--
Christian Theune · c...@flyingcircus.io · +49 345
Hi,
(I hope I’m not double posting. My mail client was misconfigured and I think I
only managed to send the mail correctly this time.)
I’m currently shrinking a device and it seems that the performance of shrink is
abysmal. I intended to shrink a ~22TiB filesystem down to 20TiB. This is still
Hi,
I’m currently shrinking a device and it seems that the performance of shrink is
abysmal. I intended to shrink a ~22TiB filesystem down to 20TiB. This is still
using LVM underneath so that I can’t just remove a device from the filesystem
but have to use the resize command.
Label: 'backy' u
42 matches
Mail list logo
