Hi, I thought that I would attempt a quick little patch that will make btrfsck into a No-op when called as fsck.btrfsck. The reasoning is that the FAQ states that it is recommended and safe to do so, and the current 12.04 version of Ubuntu just symlinks fsck.btrfsck to btrfsck instead of /bin/true. PS - Apologies if I mess this git send-email up! Dan McGrath (1): btrfs-progs: No-op when called as fsck.btrfsck btrfs.c | 2 ++ 1 file changed, 2 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
As per FAQ: It is safe to and recommended to turn fsck.btrfs into a no-op Signed-off-by: Dan McGrath <danmcgrath.ca@gmail.com> --- btrfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/btrfs.c b/btrfs.c index 691adef..78161a9 100644 --- a/btrfs.c +++ b/btrfs.c @@ -272,6 +272,8 @@ int main(int argc, char **argv) if (!strcmp(bname, "btrfsck")) { argv[0] = "check"; + } else if (!strcmp(bname, "fsck.btrfsck")) { + exit(0); } else { argc--; argv++; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Jan Alexander Steffens
2013-Apr-15 14:03 UTC
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
On Mon, Apr 15, 2013 at 3:47 PM, Dan McGrath <danmcgrath.ca@gmail.com> wrote:> As per FAQ: It is safe to and recommended to turn fsck.btrfs into a no-op > > Signed-off-by: Dan McGrath <danmcgrath.ca@gmail.com> > --- > btrfs.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/btrfs.c b/btrfs.c > index 691adef..78161a9 100644 > --- a/btrfs.c > +++ b/btrfs.c > @@ -272,6 +272,8 @@ int main(int argc, char **argv) > > if (!strcmp(bname, "btrfsck")) { > argv[0] = "check"; > + } else if (!strcmp(bname, "fsck.btrfsck")) { > + exit(0); > } else { > argc--; > argv++; > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.htmlShouldn''t it be fsck.btrfs, not fsck.btrfsck? Also, fsck.xfs does a bit more than just an exit(0), maybe there''s some merit to what it does. It''s a simple shellscript, so check it out. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dan McGrath
2013-Apr-15 14:10 UTC
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
My sincere apologies. It would appear that I was overly careful about checking the binary functioned when called as a symlink, but not the correct filename: # ls -l `which fsck.btrfs` lrwxrwxrwx 1 root root 7 Aug 25 2011 /sbin/fsck.btrfs -> btrfsck So yes, the patch incorrectly assumed a symlink name of ''fsck.btrfsck'', instead of ''fsck.btrfs''. As for fsck.xfs, I will take a look, thanks! On Mon, Apr 15, 2013 at 10:03 AM, Jan Alexander Steffens <jan.steffens@gmail.com> wrote:> > On Mon, Apr 15, 2013 at 3:47 PM, Dan McGrath <danmcgrath.ca@gmail.com> wrote: > > As per FAQ: It is safe to and recommended to turn fsck.btrfs into a no-op > > > > Signed-off-by: Dan McGrath <danmcgrath.ca@gmail.com> > > --- > > btrfs.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/btrfs.c b/btrfs.c > > index 691adef..78161a9 100644 > > --- a/btrfs.c > > +++ b/btrfs.c > > @@ -272,6 +272,8 @@ int main(int argc, char **argv) > > > > if (!strcmp(bname, "btrfsck")) { > > argv[0] = "check"; > > + } else if (!strcmp(bname, "fsck.btrfsck")) { > > + exit(0); > > } else { > > argc--; > > argv++; > > -- > > 1.7.9.5 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Shouldn''t it be fsck.btrfs, not fsck.btrfsck? > > Also, fsck.xfs does a bit more than just an exit(0), maybe there''s > some merit to what it does. It''s a simple shellscript, so check it > out.-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Eric Sandeen
2013-Apr-15 16:38 UTC
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
On 4/15/13 9:03 AM, Jan Alexander Steffens wrote:> On Mon, Apr 15, 2013 at 3:47 PM, Dan McGrath <danmcgrath.ca@gmail.com> wrote: >> As per FAQ: It is safe to and recommended to turn fsck.btrfs into a no-op >> >> Signed-off-by: Dan McGrath <danmcgrath.ca@gmail.com> >> --- >> btrfs.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/btrfs.c b/btrfs.c >> index 691adef..78161a9 100644 >> --- a/btrfs.c >> +++ b/btrfs.c >> @@ -272,6 +272,8 @@ int main(int argc, char **argv) >> >> if (!strcmp(bname, "btrfsck")) { >> argv[0] = "check"; >> + } else if (!strcmp(bname, "fsck.btrfsck")) { >> + exit(0); >> } else { >> argc--; >> argv++; >> -- >> 1.7.9.5 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > Shouldn''t it be fsck.btrfs, not fsck.btrfsck? > > Also, fsck.xfs does a bit more than just an exit(0), maybe there''s > some merit to what it does. It''s a simple shellscript, so check it > out.Yup I think the idea for xfs was that if called by initscripts w/ common initscript options, be nice and quiet, but if it looks like it was invoked by someone expecting something to happen, be more informative. Git blame of the shell script is at http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=blame;f=fsck/xfs_fsck.sh;h=c5a96e688b994c36d9ab1b0206225f2f5e7b12e8;hb=HEAD - it hasn''t changed in forever but you might get some hints at why it does what it does. Expecting fsck.$FS in initscripts is just a leftover from pre-journaling-fs days, I think. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dan McGrath
2013-Apr-15 16:45 UTC
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
Jan, I got a chance to sit down and dig a little bit deeper into `fsck.xfs`. Here is what I discovered. The "(a|A|y|p)" options in the XFS script appear to be nothing more than the expected `fsck` options that imply automated checks (as is clearly implied by the use of AUTO). While I have yet to specifically test the capitalized "A", my guess is that it matches the "-A" options from fsck(8) for when the system is going through the fstab. The syntax itself appears to assume that the dev name is the last param (as indicated by the argc/$#, which gets eval''d into the DEV variable). After doing some tests with a hacked up version of the `fsck.xfs` script, it would appear that the generic `fsck` script calls each script in order and passes it some parameters to test, since if I pass `fsck` some random/btrfsck switches: # fsck --repair /dev/storage/lv_btrfs I get an error back from `fsck.ext4`: fsck from util-linux 2.20.1 fsck.ext4: invalid option -- ''e'' Since the man page for fsck(8) hints that there are no real standards for calling conventions, but most support (a|n|r|y), and as how unknown options cause an error with fsck (thanks to ext4), perhaps it would be a good idea for btrfsck to align itself with the standard options for fsck (a/n/r/y/A)? If anything, the "A" option (for fstab based) would appear to be the real target of a noop style exit(0) that I had originally tested. Also, thanks for the link Eric, just came in as I am typing this reply :) Anyways, thought I would reply back with some insight on the matter and see what others had to say, since I am in no position to dictate the direction that brtfsck/fsck.btrfs should take as far as wrapper script or no is concerned. Look forward to your replies! o/ Dan On Mon, Apr 15, 2013 at 10:03 AM, Jan Alexander Steffens <jan.steffens@gmail.com> wrote:> On Mon, Apr 15, 2013 at 3:47 PM, Dan McGrath <danmcgrath.ca@gmail.com> wrote: >> As per FAQ: It is safe to and recommended to turn fsck.btrfs into a no-op >> >> Signed-off-by: Dan McGrath <danmcgrath.ca@gmail.com> >> --- >> btrfs.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/btrfs.c b/btrfs.c >> index 691adef..78161a9 100644 >> --- a/btrfs.c >> +++ b/btrfs.c >> @@ -272,6 +272,8 @@ int main(int argc, char **argv) >> >> if (!strcmp(bname, "btrfsck")) { >> argv[0] = "check"; >> + } else if (!strcmp(bname, "fsck.btrfsck")) { >> + exit(0); >> } else { >> argc--; >> argv++; >> -- >> 1.7.9.5 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > Shouldn''t it be fsck.btrfs, not fsck.btrfsck? > > Also, fsck.xfs does a bit more than just an exit(0), maybe there''s > some merit to what it does. It''s a simple shellscript, so check it > out.-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Eric Sandeen
2013-Apr-15 17:01 UTC
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
On 4/15/13 11:45 AM, Dan McGrath wrote:> Jan, > > I got a chance to sit down and dig a little bit deeper into > `fsck.xfs`. Here is what I discovered. > > The "(a|A|y|p)" options in the XFS script appear to be nothing more > than the expected `fsck` options that imply automated checks (as is > clearly implied by the use of AUTO). While I have yet to specifically > test the capitalized "A", my guess is that it matches the "-A" options > from fsck(8) for when the system is going through the fstab. The > syntax itself appears to assume that the dev name is the last param > (as indicated by the argc/$#, which gets eval''d into the DEV > variable). > > After doing some tests with a hacked up version of the `fsck.xfs` > script, it would appear that the generic `fsck` script calls each > script in order and passes it some parameters to test, since if I pass > `fsck` some random/btrfsck switches: > > # fsck --repair /dev/storage/lv_btrfs > > I get an error back from `fsck.ext4`: > > fsck from util-linux 2.20.1 > fsck.ext4: invalid option -- ''e''2 things; from the fsck manpage: fsck [-sAVRTMNP] [-C [fd]] [-t fstype] [filesys...] [--] [fs-specific-options] so I think you need: fsck -- --repair /dev/storage/lv_btrfs But the other issues seems to be that fsck & blkid are autodetecting the device as ext4, not btrfs; a separate issue. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dan McGrath
2013-Apr-15 17:23 UTC
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
Jan, It would appear that: # fsck -- --repair /dev/storage/lv_btrfs doesn''t work, but if I put the fs-specific-options at the end: # fsck /dev/storage/lv_btrfs -- --repair it works fine. As we were/are discussing on irc, I also have no idea where the ext4 lines come from. *scratcheshead* And to save you guys some testing, here is the script I used and some sample output: fsck.btrfs: =======#!/bin/sh -f # fsck exit codes for convenience # 0 - No errors # 1 - Filesystem errors corrected # 2 - System should be rebooted # 4 - Filesystem errors left uncorrected # 8 - Operational error # 16 - Usage or syntax error # 32 - Fsck canceled by user request # 128 - Shared-library error AUTO=false while getopts ":aApy" c do case $c in a|A|p|y) AUTO=true; echo "DEBUG: $c";; esac done eval DEV=\${$#} if [ ! -e $DEV ]; then echo "$0: $DEV does not exist" exit 8 fi if $AUTO; then echo "$0: BTRFS file system." else echo "If you wish to check the consistency of an BTRFS filesystem or" echo "repair a damaged filesystem, see btrfsck(8)." fi exit 0 ======= Output: =====# fsck /dev/storage/lv_btrfs -- --repair fsck from util-linux 2.20.1 DEBUG: p DEBUG: a /sbin/fsck.btrfs: BTRFS file system. # fsck /dev/storage/lv_btrfs fsck from util-linux 2.20.1 If you wish to check the consistency of an BTRFS filesystem or repair a damaged filesystem, see btrfsck(8). Note the "p" and "a" switches when called with custom fs switches, but not when called standalone. On Mon, Apr 15, 2013 at 1:01 PM, Eric Sandeen <sandeen@redhat.com> wrote:> On 4/15/13 11:45 AM, Dan McGrath wrote: >> Jan, >> >> I got a chance to sit down and dig a little bit deeper into >> `fsck.xfs`. Here is what I discovered. >> >> The "(a|A|y|p)" options in the XFS script appear to be nothing more >> than the expected `fsck` options that imply automated checks (as is >> clearly implied by the use of AUTO). While I have yet to specifically >> test the capitalized "A", my guess is that it matches the "-A" options >> from fsck(8) for when the system is going through the fstab. The >> syntax itself appears to assume that the dev name is the last param >> (as indicated by the argc/$#, which gets eval''d into the DEV >> variable). >> >> After doing some tests with a hacked up version of the `fsck.xfs` >> script, it would appear that the generic `fsck` script calls each >> script in order and passes it some parameters to test, since if I pass >> `fsck` some random/btrfsck switches: >> >> # fsck --repair /dev/storage/lv_btrfs >> >> I get an error back from `fsck.ext4`: >> >> fsck from util-linux 2.20.1 >> fsck.ext4: invalid option -- ''e'' > > 2 things; from the fsck manpage: > > fsck [-sAVRTMNP] [-C [fd]] [-t fstype] [filesys...] [--] [fs-specific-options] > > so I think you need: > > fsck -- --repair /dev/storage/lv_btrfs > > But the other issues seems to be that fsck & blkid are autodetecting > the device as ext4, not btrfs; a separate issue. > > -Eric > >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Zach Brown
2013-Apr-15 18:59 UTC
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
> Anyways, thought I would reply back with some insight on the matter > and see what others had to say, since I am in no position to dictate > the direction that brtfsck/fsck.btrfs should take as far as wrapper > script or no is concerned. Look forward to your replies! o/FWIW: debian has been carrying a patch to ignore fsck args to help it run as fsck.btrfs. I think modern versions of their btrfs-tools package that are based on more recent btrfs-progs also include the hunk to recognize being called as fsck.btrfs. It might be worth finding someone who knows the history of the debian package. I''m certainly not that person :). Here''s the result of some light googling: http://ftp.de.debian.org/debian/pool/main/b/btrfs-tools/btrfs-tools_0.19+20130131-3+really20121004-1.debian.tar.xz debian/patches/08-fsck.patch: Author: Sten Heinze <shze@gmx.de> Description: Ignore all arguments starting with -a in btrfsck for the time being (Closes: #567681, #571300, #612809, #668832). diff -Naurp btrfs-tools.orig/btrfsck.c btrfs-tools/btrfsck.c --- btrfs-tools.orig/btrfsck.c 2012-12-10 10:44:57.283351955 +0100 +++ btrfs-tools/btrfsck.c 2012-12-10 10:56:20.971516720 +0100 @@ -3477,6 +3477,12 @@ static void print_usage(void) exit(1); } +static void print_info(void) +{ + fprintf(stderr, "%s\n", BTRFS_BUILD_VERSION); + exit(0); +} + static struct option long_options[] = { { "super", 1, NULL, ''s'' }, { "repair", 0, NULL, 0 }, @@ -3501,7 +3507,7 @@ int main(int ac, char **av) while(1) { int c; - c = getopt_long(ac, av, "s:", long_options, + c = getopt_long(ac, av, "s:anry", long_options, &option_index); if (c < 0) break; @@ -3514,6 +3520,12 @@ int main(int ac, char **av) break; case ''?'': print_usage(); + break; + case ''a'': + case ''n'': + case ''r'': + case ''y'': + print_info(); } if (option_index == 1) { printf("enabling repair mode\n"); -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html