Modify

Opened 9 years ago

Closed 6 years ago

Last modified 6 years ago

#558 closed enhancement (fixed)

[PATCH] mountd does not recognize xfs file systems

Reported by: fon@… Owned by:
Priority: low Milestone:
Component: fon-base-firmware Version: N/A
Severity: normal
Cc: Hardware: both

Description (last modified by matthijs)

My external storage uses the xfs file system. Since the xfs.ko kernel module is not shipped with the base image, I installed this manually.

However, the xfs partition does not automount even though the xfs module is loaded at runtime.

I tracked down the problem being with mountd only recognizing ext2, ext3, vfat, hfsplus and ntfs filesystems.

I propose that mount.c be patched so that unknown filesystems also are mounted, and let the kernel detect the filesystem (i.e. do not pass the -t flag).

Patch: fonosfera_2.3.0.0_GPL/fon/mountd/src/lib/mount.c

--- mount.c.orig        2010-01-10 21:39:49.000000000 +0100
+++ mount.c     2010-01-10 21:32:42.000000000 +0100
@@ -545,26 +545,29 @@
                        log_printf("mount -t vfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
                        ret = system_printf("mount -t vfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
                }
-               if(mount->fs == EXT3)
+               else if(mount->fs == EXT3)
                {
                        log_printf("mount -t ext3 -o rw,defaults /dev/%s %s", mount->dev, tmp);
                        ret = system_printf("mount -t ext3 -o rw,defaults /dev/%s %s", mount->dev, tmp);
                }
-               if(mount->fs == EXT2)
+               else if(mount->fs == EXT2)
                {
                        log_printf("mount -t ext2 -o rw,defaults /dev/%s %s", mount->dev, tmp);
                        ret = system_printf("mount -t ext2 -o rw,defaults /dev/%s %s", mount->dev, tmp);
                }
-               if(mount->fs == HFSPLUS)
+               else if(mount->fs == HFSPLUS)
                {
                        log_printf("mount -t hfsplus -o rw,defaults,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
                        ret = system_printf("mount -t hfsplus -o rw,defaults,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
                }
-               if(mount->fs == NTFS)
+               else if(mount->fs == NTFS)
                {
                        log_printf("ntfs-3g /dev/%s %s -o force", mount->dev, tmp);
                        ret = system_printf("ntfs-3g /dev/%s %s -o force", mount->dev, tmp);
-               }
+               } else { /* fallback, let kernel decide. For example for xfs with externally loaded module */
+               log_printf("mount -o rw,defaults /dev/%s %s", mount->dev, tmp);
+               ret = system_printf("mount -o rw,defaults /dev/%s %s", mount->dev, tmp);
+                }
                exit(WEXITSTATUS(ret));
        }
        pid = waitpid(pid, &ret, 0);

Thanks,

Stefan

Attachments (0)

Change History (13)

comment:1 Changed 9 years ago by matthijs

  • Hardware set to both
  • Milestone Firmware 2.3.0 deleted
  • Status changed from new to confirmed
  • Summary changed from mountd does not recognize xfs file systems to [PATCH] mountd does not recognize xfs file systems
  • Type changed from bug to enhancement
  • Version set to 2.3.0.0 (Elan)

comment:2 Changed 9 years ago by matthijs

  • Description modified (diff)
  • Milestone set to Firmware 2.3.7.0
  • Severity set to unknown

comment:3 follow-up: Changed 9 years ago by matthijs

The patch looks good, I'll apply it.

Is it ok to credit you as "Stefan Alfredsson" in the commit log?

comment:4 in reply to: ↑ 3 Changed 9 years ago by Stefan

Replying to matthijs:

The patch looks good, I'll apply it.

Is it ok to credit you as "Stefan Alfredsson" in the commit log?

Sure!

Stefan

comment:5 Changed 9 years ago by matthijs

Hmm, did you actually test this patch? I've just tried running it (not with an actual xfs filesystem, but I think my test should be similar) and it seems that mountd will not even try to mount a filesystem when it does not succesfully detect a valid filesystem (e.g., mount_add_list will not create the mount point and symlink for it).

comment:6 Changed 9 years ago by Stefan

Well, it's been a while since I used it (ticket created 8 months ago), but now that you mention it, I seem to recall there was some other change needed as well. I've since lost the source tree in a hard drive crash, but when I get some spare time I'll try to figure out the missing parts.

comment:7 Changed 8 years ago by matthijs

Stefan, found any spare time yet? :-)

If we want to include your patch, perhaps there should be a new uci config option mountd.mountd.mount_unknown (no need for a webinterface for setting it, though). This option would cause mountd to create the mountpoint and symlinks for unrecognized partitions as well, and just let the kernel try to figure out the filesystem type as you propose. This could lead to non-working mount points for partitions that are broken or really unsupported, but I guess that's ok for users setting this.

If you can provide a patch to implement this, I can try to include it in the next release. Otherwise, it'll probably take me a while (i.e. a few releases) to get around to it, I'm afraid.

comment:8 Changed 8 years ago by Stefan

On 4/7/11 9:50 AM, fon-ng wrote:

Stefan, found any spare time yet? :-)

Yes, I worked on it some months ago, re-implemented the previous functionality, but never got it to auto-detect again; currently after (infrequent) reboots, I login, create the mount point and mount the drive manually.

If we want to include your patch, perhaps there should be a new uci config option mountd.mountd.mount_unknown (no need for a webinterface for setting it, though). This option would cause mountd to create the mountpoint and symlinks for unrecognized partitions as well, and just let the kernel try to figure out the filesystem type as you propose. This could lead to non- working mount points for partitions that are broken or really unsupported, but I guess that's ok for users setting this.

If you can provide a patch to implement this, I can try to include it in the next release. Otherwise, it'll probably take me a while (i.e. a few releases) to get around to it, I'm afraid.

Unfortunately I too have higher tasks of higher priority, which means this will not be done by me in the foreseeable future - and it works fine for me between reboots since there is no unplugging of the drive (i.e. no "itch", to cite Bruce Perens). However, would it be possible for the time being to include the xfs kernel module in the compilation? Maybe provided as a separate installable module to not bloat the image for the majority of users that do not need it.

BR,

Stefan

comment:9 Changed 8 years ago by matthijs

Understood.

As for providing the XFS module, there isn't really any obvious way in our current release process to supply separate modules / .ipk files. I could consider just including it in the main firmware. Can you tell me how big the .so file is, I don't have it compiled here?

comment:10 Changed 8 years ago by Stefan

root@Fonera:/# du -sk /lib/modules/2.6.21/*.ko|sort -rn|head 1329 /lib/modules/2.6.21/rt2860v2_ap.ko 732 /lib/modules/2.6.21/xfs.ko 152 /lib/modules/2.6.21/ext3.ko 127 /lib/modules/2.6.21/dwc_otg.ko

So about 700 kbyte, not really justifiable I think.

Regarding separate packaging, I noted the "kmod" packages in openwrt, e.g. http://downloads.openwrt.org/kamikaze/8.09.2/rb532/packages/kmod-arptables_2.6.23.17-rb532-1_mipsel.ipk but perhaps fon packaging differs from this structure. In the beginning I tried some existing packaged xfs module, but due to kernel versioning problems it did not work, and thats why I started down the road of compiling my own and trying to get it all automatic :)

comment:11 Changed 8 years ago by Stefan

Better formatting :)

root@Fonera:/# du -sk /lib/modules/2.6.21/*.ko|sort -rn|head
1329    /lib/modules/2.6.21/rt2860v2_ap.ko
732     /lib/modules/2.6.21/xfs.ko
152     /lib/modules/2.6.21/ext3.ko
127     /lib/modules/2.6.21/dwc_otg.ko

comment:12 Changed 8 years ago by matthijs

  • Milestone changed from Firmware 2.3.7.0 to Firmware 2.3

Nope, we don't have 700k to spare :-)

OpenWRT does indeed use kmod ipk modules, which we could also provide, but right now there is no place to actually distribute them. If we get around to providing automatic nightly builds, I suspect that we could enable a bunch of extra packages in there.

comment:13 Changed 6 years ago by matthijs

  • Milestone Firmware 2.3 deleted
  • Resolution set to fixed
  • Severity changed from unknown to normal
  • Status changed from confirmed to closed
  • Version changed from 2.3.0.0 (Elan) to N/A

I've just enabled the building of XFS modules in our autobuilder.

Once the next revision is committed and built by the auto-builder, the .ipk file for the xfs module can be separately downloaded here:

http://download.fonosfera.org/auto-builds/fon-ng/fon-ng-r2242/fonera2n/packages/mipsel/

(and in a similar location for future builds, of course)

Since this is as much support for XFS we will be offering now, I'm closing this ticket.

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.