On Wed, Oct 02, Jeff Mahoney wrote:

btrfstune -r <device> will fix this.

The kernel in the next release will have the ability to do this while the fs is mounted via echo 1 > /sys/fs/btrfs/<fsid>/features/extended_iref

Its this kernel: Linux hammer121 3.11.0-rc4-7.g327e5fc-default #1 SMP Sun Aug 11 19:28:11 UTC 2013 (327e5fc) x86_64 x86_64 x86_64 GNU/Linux Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 02/10/13 15:04, Tomáš Chvátal escribió:

Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.

I just tried to correct this with btrfstune but can't be issued to a mounted root filesystem.. -_- I suggest to omit the %fdupes call in the package instead. -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Oct 3, 2013 at 3:03 AM, Petr Gajdos wrote:

On Wed, Oct 02, 2013 at 03:11:58PM -0300, Cristian Rodríguez wrote:

...

El 02/10/13 15:04, Tomáš Chvátal escribió:

...

Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.

I just tried to correct this with btrfstune but can't be issued to a mounted root filesystem.. -_- I suggest to omit the %fdupes call in the package instead.

bnc#841472

%fdupes -s seems to work?

Petr

I assume you don't want to make that change for all packages. How could it be assured that every package with too many hardlinks is converted to use symbolic links? Considering users will sometimes use zypper dup to update from M to M+2 or M+3, how long would you have to leave that workaround in place? Obviously I don't like the approach. I'd rather see "zypper dup" patched to error out if: btrfs is in use for / or /usr, the current kernel is < 3.11 and the repositories it will pull from are >= 13.1. It could just tell the user that "zypper dup" upgrade is not supported for that and they need to download the DVD and upgrade that way. That has the advantage of being a permanent "fix" that won't need to be undone in the future. Then if the kernel is >= 3.11 zypper could check the filesystem and ensure it supports large numbers of hardlinks prior to starting the upgrade. After all, having these users download a DVD is not the end of the world and I would hope anyone running btrfs for / or /usr knew they were taking a risk of not having it go perfectly smoothly. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stephan Kulow wrote:

Am 03.10.2013 16:42, schrieb Greg Freemyer:

...

I'd rather see "zypper dup" patched to error out if: btrfs is in use This just replaces one egg-chicken problem with another, because the dup you need to patch is in 12.3's zypper.

Greetings, Stephan

I thought zypper in general pulled all updates to its own stack and installed them, then exited with a message that zypperneeds was updated and needs to be re-run. Is that not true also of zypper dup? Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Oct 4, 2013 at 8:21 AM, Marcus Meissner wrote:

On Fri, Oct 04, 2013 at 08:11:29AM -0400, Greg Freemyer wrote:

...

Stephan Kulow wrote:

...

Am 03.10.2013 16:42, schrieb Greg Freemyer:

...

I'd rather see "zypper dup" patched to error out if: btrfs is in use This just replaces one egg-chicken problem with another, because the dup you need to patch is in 12.3's zypper.

Greetings, Stephan

I thought zypper in general pulled all updates to its own stack and installed them, then exited with a message that zypperneeds was updated and needs to be re-run.

Is that not true also of zypper dup?

This is a flag in the patch metadata, this just works for "zypper patch".

Ciao, Marcus

Is there anything happening on this? Or is it just going to have to be addressed in the release notes? Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 02.10.2013 20:11, schrieb Cristian Rodríguez:

El 02/10/13 15:04, Tomáš Chvátal escribió:

...

Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.

I just tried to correct this with btrfstune but can't be issued to a mounted root filesystem.. -_- I suggest to omit the %fdupes call in the package instead.

break packages instead of fixing the broken file system? Seems like a plan! :-) -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Oct 3, 2013 at 11:48 AM, Jeff Mahoney wrote:

On 10/3/13 11:17 AM, Stefan Seyfried wrote:

...

Am 02.10.2013 20:11, schrieb Cristian Rodríguez:

...

El 02/10/13 15:04, Tomáš Chvátal escribió:

...

Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.

I just tried to correct this with btrfstune but can't be issued to a mounted root filesystem.. -_- I suggest to omit the %fdupes call in the package instead.

break packages instead of fixing the broken file system? Seems like a plan! :-)

This problem doesn't occur if you boot from install media and do an update. The file system *is* fixed. It's the upgrade path that doesn't have the updated tools to enable the feature on an umounted file system or the kernel that can do it online that's the problem.

-Jeff

I only see 3 options: 1) Mangle the affected packages 2) Update the kernel and userland tools in 12.3 such that zypper patch; zypper dup works 3) Designate zypper dup for configs with btrfs on / or /usr unsupported for this release cycle. I vote for 3) Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jeff Mahoney wrote:

...

2) Update the kernel and userland tools in 12.3 such that zypper patch; zypper dup works

This is easily doable. I'll get patches worked up.

Will it be: zypper patch; reboot; echo 1 > /sys/fs/btrfs/<fsid>/features/extended_iref; zypper dup Does fstab need to be updated to have a new mount option? That's not the normal upgrade path, so it begs the question of how it should be documented. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10/15/13 9:19 AM, Greg Freemyer wrote:

Jeff Mahoney wrote:

...

...

2) Update the kernel and userland tools in 12.3 such that zypper patch; zypper dup works

This is easily doable. I'll get patches worked up.

Will it be:

zypper patch; reboot; echo 1 > /sys/fs/btrfs/<fsid>/features/extended_iref; zypper dup

Basically, yeah.

Does fstab need to be updated to have a new mount option?

Nope. It's in the file system superblock. It's a permanent change.

That's not the normal upgrade path, so it begs the question of how it should be documented.

Yep. It'd be interesting to make this automatic and as-needed. i.e. fdupes fails with EMLINK and runs the echo command. -Jeff -- Jeff Mahoney SUSE Labs

El 02/10/13 15:17, Olaf Hering escribió:

On Wed, Oct 02, Tomáš Chvátal wrote:

...

Basically from 12.3 to 13.1 you need to run installer to get over it, zypper dup will never be sufficient as you have no tools available at hand to migrate the btrfs layout before the update.

Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.

That would mean to remove every hardlink from every package, it just papers over the issue. The VM has some Factory state from August. So in the end I think its ok to require an upgrade to 13.1+ via the installer.

What about adding the required step to the initrd before mounting the root filesystem ? -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.10.2013 20:36, schrieb Jeff Mahoney:

On 10/2/13 2:17 PM, Olaf Hering wrote:

...

On Wed, Oct 02, Tomáš Chvátal wrote:

...

Basically from 12.3 to 13.1 you need to run installer to get over it, zypper dup will never be sufficient as you have no tools available at hand to migrate the btrfs layout before the update.

Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.

That would mean to remove every hardlink from every package, it just papers over the issue. The VM has some Factory state from August. So in the end I think its ok to require an upgrade to 13.1+ via the installer.

Now that my VM is in the middle of the dup, maybe I will just skip that package and see what happens.

Or the fdupes macro could handle ENLINK gracefully.

The %fdupes happen during building, cpio is creating the hardlinks Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJNH9oACgkQwFSBhlBjoJb6lQCfWlcOpcneeZnRe3+eaKTlDNAU e34AoJzXGRLx71mc9Hy2CRNn2OJRG0p5 =5bIt -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org