similar to: [PATCH] fstype: f2fs support

Hi, easy series to improve the support for f2fs filesystems: while we should be able to mount them already (if the used kernel has the support for this filesystem), put in the appliance f2fs-tools, so we can also create them. Unfortunately, there isn't much in f2fs-tools, so all that can be done is simply setting a different label only when creating a filesystem. Thanks, Pino Toscano (2):

Use resize.f2fs (via f2fs_expand) to expand f2fs filesystems, if available. --- resize/resize.ml | 12 ++++++++++-- resize/virt-resize.pod | 10 ++++++++-- 2 files changed, 18 insertions(+), 4 deletions(-) diff --git a/resize/resize.ml b/resize/resize.ml index 1a21e4dff..8e4bb1b16 100644 --- a/resize/resize.ml +++ b/resize/resize.ml @@ -136,7 +136,7 @@ let debug_logvol lv = type

Pass -L $LABEL to set the label of a f2fs filesystem when creating it. --- daemon/mkfs.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/daemon/mkfs.c b/daemon/mkfs.c index cef3574..a0617a0 100644 --- a/daemon/mkfs.c +++ b/daemon/mkfs.c @@ -228,6 +228,10 @@ do_mkfs (const char *fstype, const char *device, int blocksize, ADD_ARG (argv, i, "-L"); ADD_ARG (argv, i,

Hi, this small patch series exposes one of the utility in f2fs-tools, and use it to expand f2fs partitions in virt-resize. Thanks, Pino Toscano (2): New API: f2fs_expand resize: expand f2fs partitions daemon/Makefile.am | 1 + daemon/f2fs.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++ generator/actions_core.ml | 9 +++++++++ generator/proc_nr.ml | 1 +

The fstests supports different kind of fs testing, better to cc specific fs mailing list for specific fs testing, to get better reviewing points. So record these mailing lists and files related with them in MAINTAINERS file. Signed-off-by: Zorro Lang <zlang at kernel.org> --- If someone mailing list doesn't want to be in cc list of related fstests patch, please reply this email,

It turns out that if you specify filesystem type `auto' in /etc/fstab, updatedb (the thing which updates your `locate' database) ceases to work. Here's the contents of my /etc/updatedb.conf: PRUNEFS="devpts NFS nfs afs proc smbfs autofs auto iso9660" PRUNEPATHS="/tmp /usr/tmp /var/tmp /afs /net" export PRUNEFS export PRUNEPATHS deleting the `auto' entry

Hey, I'd greatly appreciate support for fstype detection of vfat and udf so that I can get rid of my hacky userspace solutions. I'm afraid I can't provide a patch - I'm really not into kernel developmen. However, I offer a mail-hug as bounty for getting support for this in. Regards :) -- Sven-Hendrik

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, i have a clipper 5.3 application running over samba 3.0.2a in mandrake10 system. But, i don't know which kind of files system works better in clipper applications. I was using fat partion, with "fstype = fat" in my smb.conf and samba 2.2. Then i changed my server a installed mandrake10. Right now i'm using reiserfs with

hello hpa, disabled faccessat in klibc to go forward with this dash sync, and HAVE_FACCESSAT in dash config.h, no other change. please pull: git pull git://git.debian.org/users/maks/klibc.git maks

Another post-2.5.68 one. The cramfs header defines u8, so we must quiet it down. <b diff -Nru a/utils/fstype.c b/utils/fstype.c --- a/utils/fstype.c Mon Apr 28 15:10:56 2003 +++ b/utils/fstype.c Mon Apr 28 15:10:56 2003 @@ -19,7 +19,9 @@ #include <asm/byteorder.h> #include <linux/romfs_fs.h> +#define __KERNEL__ #include <linux/cramfs_fs.h> +#undef __KERNEL__ #include

Here's a patch to support JFS in fstype. Given that this runs as root, would you consider a patch to take the device as an argument rather than stdin? I get really nervous that one of these days I'm going to > rather than <. But otherwise... =) Tested against 1.0.14, but there's nothing in there that should keep it from applying against current git that I can see. Tks, Jeff

fstype is currently broken in klibc (1.1.14 and git). It segfaults on startup when not invoked with an argument. Attached patch fixes that. PS: The previously reported problems with klibc 1.1.8 don't occur anymore, thanks. Regards, J?rg -- J?rg Billeter <j@bitron.ch> -------------- next part -------------- A non-text attachment was scrubbed... Name: klibc-1.1.14-fstype-segv-1.patch

The attached patch adds support for detecting LUKS partitions (Linux Unified Key Setup - http://luks.endorphin.org/) to fstype. This makes it easier to automatically detect and activate encrypted (root) partitions from an initramfs image. The patch is now against klibc's git tree instead of klibc-1.2. Signed-off-by: David H?rdeman <david@2gen.com> -- fstype.c | 17

The attached patch adds the ability to fstype to detect lvm2 physical volumes (PV's). Signed-off-by: David H?rdeman <david@2gen.com> -------------- next part -------------- diff -Nur klibc-orig/usr/kinit/fstype/fstype.c klibc/usr/kinit/fstype/fstype.c --- klibc-orig/usr/kinit/fstype/fstype.c 2006-03-22 21:28:31.000000000 +0100 +++ klibc/usr/kinit/fstype/fstype.c 2006-03-23

From: David H?rdeman <david@2gen.com> if a partition has been used as lvm2 and has not been cleared with pvremove, fstype would recognise the ext3 partition as lvm2. workaround that by detection lvm2 after ext3. Bonuspoint remove long fs list as this one just generates conflicts. Signed-off-by: David H?rdeman <david@2gen.com> Signed-off-by: maximilian attems

Similarly to the fix which was applied earlier which moved LVM detection to the bottom of the list in fstype, we also need to move luks detection to the end of the list since a LUKS signature leftover could co-exist with a regular fs. Regards, David -------------- next part -------------- diff --git a/usr/kinit/fstype/fstype.c b/usr/kinit/fstype/fstype.c index cea219e..89203e1 100644 ---

The test for a "-" argument on the command line is reversed, so that fstype will only attempt to open a file name provided on the command line if it is "-", rather than only if it is not "-". This patch fixes that. Signed-off-by: Colin Watson <cjwatson at ubuntu.com> diff -Nru klibc-1.4.30/usr/kinit/fstype/main.c klibc-1.4.30.new/usr/kinit/fstype/main.c ---

[please note that I'm not subscribed to the list] Hi guys, I've noticed that the size returned by the fstype utility was not correct for JFS filesystems (it returns the size in number of HW blocks instead of bytes). Here is a simple patch that addresses it (based on 1.5.7 from the debian package). diff -Nur klibc-1.5.7.orig/usr/kinit/fstype/fstype.c

Make check_for_modules() more readable, just allways call continue on NULL return. That way the possible null dereference in strlen is no longer possible. This doesn't yet make it unsuck, but is a small step. Seen fixed too in blkid there with patch adding ko.gz support. Cc: Karel Zak <kzak at redhat.com> Signed-off-by: maximilian attems <max at stro.at> ---

Helge Deller dixit: >On hppa/parisc we still need executable stacks for the signal >trampoline return code. Might your patch then maybe break fstype on >hppa? I didn't tested it... I think it only changed the assembly parts of the library to signal to the linker that there?s no need for an executable stack on their account, but the signal handling code should? add one on hppa then.