Re: Clarification needed about libbtrfs & libbtrfsutil
On 14 May 2018 at 21:22, Omar Sandoval wrote: > On Mon, May 14, 2018 at 09:40:19AM +0100, Dimitri John Ledkov wrote: >> Are both of these meant to be public libraries, installed on the user >> systems, and available in .so variant as well for 3rd party >> development and public dynamic linking? >> >> Or are these private internal libraries, which are installed as public >> runtime only, simply to share code between the utils, but otherwise >> provide no abi stability and will forever remain libfoo.so.0? > > They're both meant to be public. In fact, libbtrfsutil is already 1.0.0. > Ack. Will ship them as such. >> Or should these even be a noinst_ libraries (~= Libtool Convenience >> Libraries), and are simply intermediate by-products? >> >> I'm asking because despite compiling shared & static variants of these >> libraries, and "shared linked" and "static linked" variants of the >> utils, it appears that all utilities are statically linking against >> libbtrfs/libbtrfsutils. Thus no binaries nor bindings, dynamically >> link against neither libbtrfs nor libbtrfsutil. >> >> Tweaking the makefile to use libs_shared variable instead of libs or >> libs_static, results in slightly smaller binaries, dynamically linked >> against libbtrfs/libbtrfsutil. >> >> But it is hard to tell if this is a bug/mistake, or an intentional feature. > > I'm not sure why we statically link libbtrfs into the the tools, and I > just copied that for libbtrfsutil. OK. I guess I can prepare a patch to dynamically link libbtrfs/libbtrfsutil and see how that will go through review. -- Regards, Dimitri. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Clarification needed about libbtrfs & libbtrfsutil
Are both of these meant to be public libraries, installed on the user systems, and available in .so variant as well for 3rd party development and public dynamic linking? Or are these private internal libraries, which are installed as public runtime only, simply to share code between the utils, but otherwise provide no abi stability and will forever remain libfoo.so.0? Or should these even be a noinst_ libraries (~= Libtool Convenience Libraries), and are simply intermediate by-products? I'm asking because despite compiling shared & static variants of these libraries, and "shared linked" and "static linked" variants of the utils, it appears that all utilities are statically linking against libbtrfs/libbtrfsutils. Thus no binaries nor bindings, dynamically link against neither libbtrfs nor libbtrfsutil. Tweaking the makefile to use libs_shared variable instead of libs or libs_static, results in slightly smaller binaries, dynamically linked against libbtrfs/libbtrfsutil. But it is hard to tell if this is a bug/mistake, or an intentional feature. -- Regards, Dimitri. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "@" prefix in subvolume paths
On 11 June 2015 at 02:50, Jeff Mahoney wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 6/10/15 7:10 PM, Hugo Mills wrote: >> On Tue, Jun 09, 2015 at 07:55:05PM +0200, pu...@xs4all.nl wrote: >>> Hi, >>> >>> I've noticed this "@" sign in the subvolume's path with SLES12. >>> I'm wondering what is its purpose. openSUSE 13.2 doesn't seem to >>> be using it. >> >> They created a subvolume called "@" and then put all the other >> subvolumes under there. There's nothing special about it. >> >> The @ is often used as a prefix on subvolumes (e.g. in Ubuntu) to >> indicate that they're subvolumes, but it's not required, and >> doesn't have any extra meaning beyond being a useful naming >> convention. > > Yep. That explanation is accurate but is missing the rest of the > story. The choice of @ is probably due to following the convention > started by the Ubuntu folks but also because it's the least > complicated of the alternative names we could have used. The @ > subvolume is set as the default subvolume. As you'd expect, it's > mounted at / and used as such. The reason we use a separate subvolume > is so we can easily implement our boot-and-rollback-from-snapshot > functionality in SLE12. Having the root file system as a separate > subvolume means we can move one of the snapshot subvolumes into the fs > tree root, move the other @ subvolumes into that subvolume, and we > have a rolled back system from which we can easily remove the > now-unused root. If we didn't use a separate subvolume for it, it > would make the rollback very complicated. It's used in concert with > our GRUB implementation that iterates and presents possible snapshots > to use as a root file system in lieu of the "real" one should a > problem occur. > Interesting, can you point out to that GRUB implementation bits? On at least Ubuntu i believe we currently require to boot off @ subvolume, and don't offer the option to boot into a snapshot. But that would be very disarable, since e.g. with apt-snapshot installed we do generate checkpoint snapshot before each upgrade. Getting easy option to roll back to that would be awesome. Regards, Dimitri. > - -Jeff > >>> >>> SLES12: # btrfs sub list / ID 257 gen 2270 top level 5 path @ ID >>> 258 gen 1655 top level 257 path @/boot/grub2/i386-pc ID 259 gen >>> 4263 top level 257 path @/boot/grub2/x86_64-efi ID 260 gen 4037 >>> top level 257 path @/opt ID 261 gen 2553 top level 257 path >>> @/srv ID 262 gen 4521 top level 257 path @/tmp ID 263 gen 4492 >>> top level 257 path @/usr/local ID 264 gen 1655 top level 257 path >>> @/var/crash ID 265 gen 1655 top level 257 path @/var/lib/mailman >>> ID 266 gen 1655 top level 257 path @/var/lib/named ID 267 gen >>> 1655 top level 257 path @/var/lib/pgsql ID 268 gen 4523 top level >>> 257 path @/var/log ID 269 gen 1655 top level 257 path @/var/opt >>> ID 270 gen 4524 top level 257 path @/var/spool ID 271 gen 4521 >>> top level 257 path @/var/tmp ID 275 gen 4505 top level 257 path >>> @/.snapshots >>> >>> >>> openSUSE 13.2: >>> >>> # btrfs subvol list / ID 257 gen 3481911 top level 5 path >>> boot/grub2/i386-pc ID 258 gen 3481911 top level 5 path >>> boot/grub2/x86_64-efi ID 259 gen 3517714 top level 5 path home ID >>> 260 gen 3515789 top level 5 path opt ID 261 gen 3513493 top level >>> 5 path srv ID 262 gen 3513372 top level 5 path tmp ID 263 gen >>> 3517660 top level 5 path usr/local ID 264 gen 3513372 top level 5 >>> path var/crash ID 265 gen 3513372 top level 5 path >>> var/lib/mailman ID 266 gen 3513372 top level 5 path >>> var/lib/named ID 267 gen 3513372 top level 5 path var/lib/pgsql >>> ID 268 gen 3517714 top level 5 path var/log ID 269 gen 3513372 >>> top level 5 path var/opt ID 270 gen 3517714 top level 5 path >>> var/spool ID 271 gen 3517706 top level 5 path var/tmp ID 276 gen >>> 3517669 top level 5 path .snapshots >> > > > - -- > Jeff Mahoney > SUSE Labs > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > > iQIcBAEBAgAGBQJVeOlbAAoJEB57S2MheeWy0JYP/1mbM5ybHNcwEB21CbS+5ujv > omBmiVhX6nAcTDAJ2OJG7MsrE4L1j93R8gv/xRkPjBLuaiqJ+wr88VaG/AcKvtSZ > qMF64PJCNzsXFd0FFPi8CNXxhVbJyEKF+m8Xl+tfRsMhsNIKdbqkMHInMc99qWJH > dMLTSYObvdo9AYIkOj8PM6nBjeQ4zEBQY9uOf9M9HL8Ulc1VQgzSu1giuvHg8/Cf > Ela2iZJi2APZeNisQtQcJssMyBaDTbSH0RhQh8kcdfG6GCruSDR8AWbyuY36OeaG > 5Ifp4J7oSS+eUwlTtvLFfZl079VmJWZbF/KEy8GfY++kp+BVB95Z8QOKVOVTEA8A > 4AvkMfdGvtykZJNRskXGaIsUIX07iTmT2f+VyN7jbfp2J5FyBALp+i4Ub5fyjUZG > +OWcAIkTC9z2AQW77ZMdA4DdkHk5bi3aRSCNV1gSPGDib5CH5ZLyMY/KKtxCLSnO > syNdcZmQs4bb7FZBfcM4CQraUYsnBl4ArGechkMWpJCrMx2dtRrGlKlh+7KmG+m8 > 60xBKU3ApmZrcKUTAcWvN2cy72xmc8GZaOPnNepAUhMLduarsEtyCemOkGCZxRiu > c0QRGhGBgK91MBF1KxXzrnO0cm1ijdjMAbwmol6vEYRzXItXK3AeD74IeY6Abqr/ > U2lTFYlKYpkTmzhk0gM8 > =lO/K > -END PGP SIGNATURE- > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Dimitri. -
[PATCH] fsck.btrfs: Fix bashism and bad getopts processing
First fix == bashism, as that is not accepted by e.g. Debian/Ubuntu
dash.
Secondly shift OPTIND, such that last parameter is checked to exist.
Signed-off-by: Dimitri John Ledkov
---
fsck.btrfs | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fsck.btrfs b/fsck.btrfs
index f056a7f..20b070a 100755
--- a/fsck.btrfs
+++ b/fsck.btrfs
@@ -26,12 +26,13 @@ do
a|A|p|y)AUTO=true;;
esac
done
+shift $(($OPTIND -1))
eval DEV=\${$#}
if [ ! -e $DEV ]; then
echo "$0: $DEV does not exist"
exit 8
fi
-if [ "$AUTO" == "false" ]; then
+if ! $AUTO; then
echo "If you wish to check the consistency of a BTRFS filesystem or"
echo "repair a damaged filesystem, see btrfs(8) subcommand 'check'."
fi
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix bashism in fsck.btrfs for debian/ubuntu dash.
On 15 May 2015 at 21:28, Dimitri John Ledkov wrote: > Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784911 > Signed-off-by: Dimitri John Ledkov > --- > fsck.btrfs | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fsck.btrfs b/fsck.btrfs > index f056a7f..3a92804 100755 > --- a/fsck.btrfs > +++ b/fsck.btrfs > @@ -31,7 +31,7 @@ if [ ! -e $DEV ]; then > echo "$0: $DEV does not exist" > exit 8 > fi > -if [ "$AUTO" == "false" ]; then > +if [ "false" = "$AUTO" ]; then > echo "If you wish to check the consistency of a BTRFS filesystem or" > echo "repair a damaged filesystem, see btrfs(8) subcommand 'check'." > fi There was a lot of discussion about this trivial patch, mostly because it's so trivial and has many ways to fix. I hope btrfs maintainers could implement & push any of the proposed ways to resolve this bashism to rule them all =) -- Regards, Dimitri. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix bashism in fsck.btrfs for debian/ubuntu dash.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784911 Signed-off-by: Dimitri John Ledkov --- fsck.btrfs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fsck.btrfs b/fsck.btrfs index f056a7f..3a92804 100755 --- a/fsck.btrfs +++ b/fsck.btrfs @@ -31,7 +31,7 @@ if [ ! -e $DEV ]; then echo "$0: $DEV does not exist" exit 8 fi -if [ "$AUTO" == "false" ]; then +if [ "false" = "$AUTO" ]; then echo "If you wish to check the consistency of a BTRFS filesystem or" echo "repair a damaged filesystem, see btrfs(8) subcommand 'check'." fi -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Drop feature defines from C files, in favour of CFLAGS defines.
glibc 2.10+ (5+ years old) enables all the desired features: _XOPEN_SOURCE 700, __XOPEN2K8, POSIX_C_SOURCE, DEFAULT_SOURCE; with a single _GNU_SOURCE define in the makefile alone. For portability to other libc implementations (e.g. dietlibc) _XOPEN_SOURCE=700 is also defined. This also resolves Debian bug report filed by Michael Tautschnig - "Inconsistent use of _XOPEN_SOURCE results in conflicting declarations". Whilst I was not able to reproduce the results, the reported fact is that _XOPEN_SOURCE set to 500 in one set of files (e.g. cmds-filesystem.c) generates/defines different struct stat from other files (cmds-replace.c). This patch thus cleans up all feature defines, and sets them at a consistent level. Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747969 Signed-off-by: Dimitri John Ledkov --- Makefile | 2 +- btrfs-calc-size.c | 2 -- btrfs-convert.c | 3 --- btrfs-corrupt-block.c | 2 -- btrfs-find-root.c | 2 -- btrfs-fragments.c | 1 - btrfs-image.c | 2 -- btrfs-list.c | 1 - btrfs-map-logical.c | 2 -- btrfs-select-super.c | 2 -- btrfs-show-super.c| 2 -- btrfs-zero-log.c | 2 -- btrfs.c | 1 - btrfstune.c | 2 -- chunk-recover.c | 2 -- cmds-check.c | 2 -- cmds-filesystem.c | 1 - cmds-receive.c| 5 - cmds-restore.c| 2 -- cmds-send.c | 1 - disk-io.c | 3 --- extent_io.c | 2 -- mkfs.c| 3 --- send-test.c | 2 -- super-recover.c | 3 --- utils-lib.c | 2 -- utils.c | 4 volumes.c | 2 -- 28 files changed, 1 insertion(+), 59 deletions(-) diff --git a/Makefile b/Makefile index 8b843bb..4d7cb4a 100644 --- a/Makefile +++ b/Makefile @@ -4,7 +4,7 @@ export CC = gcc LN = ln AR = ar -AM_CFLAGS = -Wall -D_FILE_OFFSET_BITS=64 -DBTRFS_FLAT_INCLUDES -fno-strict-aliasing -fPIC +AM_CFLAGS = -Wall -D_FILE_OFFSET_BITS=64 -DBTRFS_FLAT_INCLUDES -D_XOPEN_SOURCE=700 -D_GNU_SOURCE -fno-strict-aliasing -fPIC CFLAGS = -g -O1 -fno-strict-aliasing LDFLAGS = -rdynamic objects = ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o \ diff --git a/btrfs-calc-size.c b/btrfs-calc-size.c index 50c..17d048c 100644 --- a/btrfs-calc-size.c +++ b/btrfs-calc-size.c @@ -16,8 +16,6 @@ * Boston, MA 021110-1307, USA. */ -#define _XOPEN_SOURCE 500 -#define _GNU_SOURCE 1 #include #include #include diff --git a/btrfs-convert.c b/btrfs-convert.c index bbd19bb..da10ad6 100644 --- a/btrfs-convert.c +++ b/btrfs-convert.c @@ -16,9 +16,6 @@ * Boston, MA 021110-1307, USA. */ -#define _XOPEN_SOURCE 600 -#define _GNU_SOURCE 1 - #include "kerncompat.h" #include diff --git a/btrfs-corrupt-block.c b/btrfs-corrupt-block.c index b477e87..6b9dac5 100644 --- a/btrfs-corrupt-block.c +++ b/btrfs-corrupt-block.c @@ -16,8 +16,6 @@ * Boston, MA 021110-1307, USA. */ -#define _XOPEN_SOURCE 500 -#define _GNU_SOURCE 1 #include #include #include diff --git a/btrfs-find-root.c b/btrfs-find-root.c index 6fa61cc..3517107 100644 --- a/btrfs-find-root.c +++ b/btrfs-find-root.c @@ -16,8 +16,6 @@ * Boston, MA 021110-1307, USA. */ -#define _XOPEN_SOURCE 500 -#define _GNU_SOURCE 1 #include #include #include diff --git a/btrfs-fragments.c b/btrfs-fragments.c index 360f10f..d742f60 100644 --- a/btrfs-fragments.c +++ b/btrfs-fragments.c @@ -14,7 +14,6 @@ * Boston, MA 021110-1307, USA. */ -#define _GNU_SOURCE #include #include #include diff --git a/btrfs-image.c b/btrfs-image.c index cb17f16..0485c8f 100644 --- a/btrfs-image.c +++ b/btrfs-image.c @@ -16,8 +16,6 @@ * Boston, MA 021110-1307, USA. */ -#define _XOPEN_SOURCE 500 -#define _GNU_SOURCE 1 #include #include #include diff --git a/btrfs-list.c b/btrfs-list.c index 50edcf4..3e29cf8 100644 --- a/btrfs-list.c +++ b/btrfs-list.c @@ -16,7 +16,6 @@ * Boston, MA 021110-1307, USA. */ -#define _GNU_SOURCE #include #include #include "ioctl.h" diff --git a/btrfs-map-logical.c b/btrfs-map-logical.c index 47d1104..c235d44 100644 --- a/btrfs-map-logical.c +++ b/btrfs-map-logical.c @@ -16,8 +16,6 @@ * Boston, MA 021110-1307, USA. */ -#define _XOPEN_SOURCE 500 -#define _GNU_SOURCE 1 #include #include #include diff --git a/btrfs-select-super.c b/btrfs-select-super.c index 6231d42..063ffa3 100644 --- a/btrfs-select-super.c +++ b/btrfs-select-super.c @@ -16,8 +16,6 @@ * Boston, MA 021110-1307, USA. */ -#define _XOPEN_SOURCE 500 -#define _GNU_SOURCE 1 #include #include #include diff --git a/btrfs-show-super.c b/btrfs-show-super.c index 2b48f44..4afa852 100644 --- a/btrfs-show-super.c +++ b/btrfs-show-super.c @@ -16,8 +16,6 @@ * Boston, MA 021110-1307, USA. */ -#define _XOPEN_SOURCE 500 -#define _GNU_SOURCE 1 #include #include #include diff --git a/btrfs-zero-log.c b/btrfs-zero-log.c index 4154175..31e7481 100644 --- a/btrfs-zer
Re: Announcements for btrfs-progs?
On 11 December 2014 at 12:37, Holger Hoffstätte wrote: > > David, > > I was wondering if you could please send out announcements for btrfs-progs > when you tag a release or -rc? There doesn't seem to be a good mechanism > to track releases and IMHO the more people are notified, the more > testing we can get, not to mention faster propagation into distros. > I subscribe to the RSS feeds of the btrfs git repositories thus notice new commits / tags. However, I did miss when btrfs git repository shifted release maintainers and thus changed the repository i should be subscribed to. But, I don't currently package nor test RC tarballs, only released versions and after dust settles. -- Regards, Dimitri. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2] mount.btrfs helper
On 5 December 2014 at 15:32, Chris Mason wrote: > On Sun, Nov 30, 2014 at 5:57 PM, Dimitri John Ledkov > wrote: >> >> On 30 November 2014 at 22:31, cwillu wrote: >>> >>> >>> In ubuntu, the initfs runs a btrfs dev scan, which should catch >>> anything that would be missed there. >>> >> >> I'm sorry, udev rule(s) is not sufficient in the initramfs-less case, >> as outlined. >> >> In case of booting with initramfs, indeed, both Debian & Ubuntu >> include snippets there to run btrfs scan. > > > In an initramfs-less system, the root filesystem mount is done by the > kernel, without calling any mount.btrfs. The mount helper has all the same > problems that calling btrfs dev scan does, it's just being run by mount. > Sure. in my initramfs-less system case the root filesystem was not btrfs. Simply there was a btrfs filesystem defined in /etc/fstab. > I definitely agree that assembling the filesystem from userland is somewhat > awkward, and people that don't want initrds end up needing to jump through > hoops to get things done. > > But, the tools we have to avoid the hoops are initrds and udev, and I'd much > rather spend time fixing filesystem bugs than recreating those tools. If > people are having trouble with udev, or having trouble with tools in the > initrd, lets contribute fixes to those projects instead. > > For people that really really don't want initrds, pass the devices on the > command line. If that isn't working, we'll fix it, but if you really want a > scan, please try an initrd. You can even make one without any kernel > modules, and then you don't have to recreate it until you want to update the > userland in your initrd. > The other suggestion I received is to ship a systemd unit that does unconditional btrfs scan pre local filesystem target... =) kernel-module-less initrd sounds cool, i'll experiment with that. -- Regards, Dimitri. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Btrfs: add sha256 checksum option
On 30 November 2014 at 22:59, Christoph Anton Mitterer wrote: >>Agree with others about -C 256...-C sha256 is only three >>letters more ;) > > Ideally, sha2-256 would be used, since there will be (are) other > versions of sha which have 256 bits size. > Nope, we should use standard names. SHA-2 256 was the first SHA algo to use 256 bits, thus it's commonly referred to as sha256 across the board in multiple pieces of software. SHA-3 family of hashes started to have the same length and thus will be known as sha3-256 etc. Shorthand variant names in this table here http://en.wikipedia.org/wiki/SHA-1#Comparison_of_SHA_functions appear to me how SHA hashes are currently referred as. -- Regards, Dimitri. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2] mount.btrfs helper
On 30 November 2014 at 22:31, cwillu wrote: > > In ubuntu, the initfs runs a btrfs dev scan, which should catch > anything that would be missed there. > I'm sorry, udev rule(s) is not sufficient in the initramfs-less case, as outlined. In case of booting with initramfs, indeed, both Debian & Ubuntu include snippets there to run btrfs scan. -- Regards, Dimitri. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2] mount.btrfs helper
Hello, On 30 November 2014 at 17:43, Goffredo Baroncelli wrote: > Hi all, > > this patch provides a "mount.btrfs" helper for the mount command. > A btrfs filesystem could span several disks. This helper scans all the > partitions to discover all the disks required to mount a filesystem. > So it would not necessary any-more to "scan" the partitions to mount a > filesystem. > I would welcome this, as a general idea. At the moment in debian & ubuntu, btrfs tools package ships udev rules to call "btrfs scan" whenever device nodes appear. If scan is built into mount, I would be able to drop that udev rule. There are also some reports (not yet re-verified) that such udev rule is not effective, that is btrfs mount fails when attempted before udev has attempted to be run - e.g. from initrdless boot trying to mount btrfs systems before udev-trigger has been run (to process "cold-plug" events). -- Regards, Dimitri. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] Default to acting like fsck.
On 21 September 2014 13:59, Tobias Geerinckx-Rice
wrote:
> On 21 September 2014 03:01, Dimitri John Ledkov wrote:
>>
>> Inspect arguments, if we are not called as btrfs, then assume we are
>> called to act like fsck.
> [...]
>> - if (!strcmp(bname, "btrfsck")) {
>> + if (strcmp(bname, "btrfs") != 0) {
>
> That's assuming a lot.
>
> Silently (!) breaking people's btrfs-3.15_patched-DontRandomlyPanicV2
> is a recipe for needless hair-pulling. Is there a reason for not using
> something less like strstr(bname, "fsck") that I am missing?
>
Quite. This is verbatim patch as I have currently applied in Debian
packaging, and it was a fast fix to prevent breakage we had at one
point.
Indeed using "strstr(bname, "fsck")" would be better and sufficient to
resolve the problem we encountered (specifically fsck.btrfs -> btrfs
not acting like btrfs). Also using strstr, would fix btrfsck.my-build
to act like fsck tool.
I'll update this one patch.
--
Regards,
Dimitri.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] Fixes FTBFS with --no-add-needed.
From: Luk Claes Bug-Debian: http://bugs.debian.org/554059 Signed-off-by: Dimitri John Ledkov --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index e721e99..441e925 100644 --- a/Makefile +++ b/Makefile @@ -26,7 +26,7 @@ TESTS = fsck-tests.sh convert-tests.sh INSTALL = install prefix ?= /usr/local bindir = $(prefix)/bin -lib_LIBS = -luuid -lblkid -lm -lz -llzo2 -L. +lib_LIBS = -luuid -lblkid -lm -lz -llzo2 -lcom_err -L. libdir ?= $(prefix)/lib incdir = $(prefix)/include/btrfs LIBS = $(lib_LIBS) $(libs_static) -- 2.1.0.rc1 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] Default to acting like fsck.
Inspect arguments, if we are not called as btrfs, then assume we are
called to act like fsck.
Bug-Debian: http://bugs.debian.org/712078
Signed-off-by: Dimitri John Ledkov
---
btrfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/btrfs.c b/btrfs.c
index e83349c..e8a87ac 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -222,7 +222,7 @@ int main(int argc, char **argv)
else
bname = argv[0];
- if (!strcmp(bname, "btrfsck")) {
+ if (strcmp(bname, "btrfs") != 0) {
argv[0] = "check";
} else {
argc--;
--
2.1.0.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] Fixing unaligned memory accesses.
From: Shawn Landen
Bug-Debian: http://bugs.debian.org/656955
Signed-off-by: Dimitri John Ledkov
---
ctree.h | 18 ++
volumes.c | 5 +++--
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/ctree.h b/ctree.h
index fa73c4a..92c6ad3 100644
--- a/ctree.h
+++ b/ctree.h
@@ -19,6 +19,8 @@
#ifndef __BTRFS__
#define __BTRFS__
+#include
+
#if BTRFS_FLAT_INCLUDES
#include "list.h"
#include "kerncompat.h"
@@ -1191,13 +1193,17 @@ struct btrfs_root {
static inline u##bits btrfs_##name(const struct extent_buffer *eb) \
{ \
const struct btrfs_header *h = (struct btrfs_header *)eb->data; \
- return le##bits##_to_cpu(h->member);\
+ uint##bits##_t t; \
+ memcpy(&t, &h->member, sizeof(h->member)); \
+ return le##bits##_to_cpu(t);\
} \
static inline void btrfs_set_##name(struct extent_buffer *eb, \
u##bits val)\
{ \
struct btrfs_header *h = (struct btrfs_header *)eb->data; \
- h->member = cpu_to_le##bits(val); \
+ uint##bits##_t t; \
+ t = cpu_to_le##bits(val); \
+ memcpy(&h->member, &t, sizeof(h->member)); \
}
#define BTRFS_SETGET_FUNCS(name, type, member, bits) \
@@ -1219,11 +1225,15 @@ static inline void btrfs_set_##name(struct
extent_buffer *eb, \
#define BTRFS_SETGET_STACK_FUNCS(name, type, member, bits) \
static inline u##bits btrfs_##name(const type *s) \
{ \
- return le##bits##_to_cpu(s->member);\
+ uint##bits##_t t; \
+ memcpy(&t, &s->member, sizeof(s->member)); \
+ return le##bits##_to_cpu(t);\
} \
static inline void btrfs_set_##name(type *s, u##bits val) \
{ \
- s->member = cpu_to_le##bits(val); \
+ uint##bits##_t t; \
+ t = cpu_to_le##bits(val); \
+ memcpy(&s->member, &t, sizeof(s->member)); \
}
BTRFS_SETGET_FUNCS(device_type, struct btrfs_dev_item, type, 64);
diff --git a/volumes.c b/volumes.c
index 388c94e..102380b 100644
--- a/volumes.c
+++ b/volumes.c
@@ -472,10 +472,11 @@ static int find_next_chunk(struct btrfs_root *root, u64
objectid, u64 *offset)
if (found_key.objectid != objectid)
*offset = 0;
else {
+ u64 t;
chunk = btrfs_item_ptr(path->nodes[0], path->slots[0],
struct btrfs_chunk);
- *offset = found_key.offset +
- btrfs_chunk_length(path->nodes[0], chunk);
+ t = found_key.offset +
btrfs_chunk_length(path->nodes[0], chunk);
+ memcpy(offset, &t, sizeof(found_key.offset));
}
}
ret = 0;
--
2.1.0.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] Properly cast to avoid compiler warnings, fixes FTBFS on alpha and ia64.
Bug-Debian: http://bugs.debian.org/539433
Bug-Debian: http://bugs.debian.org/583768
Authors:
Luca Bruno
Alexander Kurtz
Daniel Baumann
Signed-off-by: Dimitri John Ledkov
---
btrfs-convert.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/btrfs-convert.c b/btrfs-convert.c
index 71b7bd6..3673050 100644
--- a/btrfs-convert.c
+++ b/btrfs-convert.c
@@ -2441,7 +2441,7 @@ static int do_rollback(const char *devname)
ext2_root = btrfs_read_fs_root(root->fs_info, &key);
if (!ext2_root || IS_ERR(ext2_root)) {
fprintf(stderr, "unable to open subvol %llu\n",
- key.objectid);
+ (unsigned long long) key.objectid);
goto fail;
}
--
2.1.0.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
