bugfindutils - Bugs: bug #14921, find -fstype broken when...

 
 

bug #14921: find -fstype broken when bind-mounts are used

Submitted by:  Andreas Metzler <ametzler>
Submitted on:  Sun 06 Nov 2005 10:22:16 AM UTC  
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Fixed
Privacy:  Public Assigned to:  James Youngman <jay>
Originator Name:  Open/Closed:  Closed
Release:  4.2.25 Fixed Release:  4.2.27

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Mon 14 May 2007 05:24:04 PM UTC, comment #9: 

Hello,
Well, lets not call it a bug but a wishlist item. I think a different behavior is preferable, with reporting  the "original" /tmp/a as ext3 and the bind-mounted "copy" as type none.

This would allow solving the suggestion in <http://bugs.debian.org/329385>:

| Having a machine with several chroot's and filesystems mounted
| with bind, these filesystems are searched over and over again.
| Please add 'none' to PRUNEFS in /etc/updatedb.conf.

cu andreas

Andreas Metzler <ametzler>
Sun 13 May 2007 10:55:20 PM UTC, comment #8: 

As I understand things, /sid/tmp/a in your example, really is on an ext3 filesystem.  What is behaviour you're describing as a bug?

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 13 May 2007 03:59:51 PM UTC, comment #7: 

Could we please have this bug marked as Open, due to my comment #6?

4.3.5 behaves exactly like I 4.2.27 in this respect.

cu andreas

Andreas Metzler <ametzler>
Sun 18 Dec 2005 09:32:27 AM UTC, comment #6: 

Hello,
Sorry for being so late in response. This is not fixed, just broken in a different way.

Jay wrote:

> OK, diagnosed and fixed.


> find was taking the LAST matching entry from /etc/mtab rather
> than the FIRST (this was also a memory leak).

[...]

> I've now fixed this in 4.2.x (and will soon propagate the fix
> to 4.3.x). We take the first match.


I bindmount /tmp to /sid/tmp; i.e. the contents of /tmp/ are afterwards also visible in /sid/tmp

With 4.2.26 this results in /tmp/a (and any other file on the same filesystem as /tmp/) and /sid/tmp/a to be both considered type "none".

OTOH with 4.2.27 this results in /tmp/a (and any other file on the same filesystem as /tmp/) and /sid/tmp/a to be both considered type "ext3".

What I'd actually like to accomplish is:
/tmp/a  type ext3
/sid/tmp/a type none

I do not know whether this doable, stat does not offer the necessary information, e.g. df(1) from coreutils uses a loop:
/* Figure out which device file or directory POINT is mounted on
   and show its disk usage.
   STATP must be the result of `stat (POINT, STATP)'.  */
static void
show_point (const char point, const struct stat statp)

cu andreas

Andreas Metzler <ametzler>
Wed 23 Nov 2005 06:49:17 AM UTC, comment #5: 

OK, diagnosed and fixed.

find was taking the LAST matching entry from /etc/mtab rather than the FIRST (this was also a memory leak).

Since the device number of /tmp/bindmounttofoo was the same as the device number of /, all files appeared to fstype.c to be on the same filesystem as /tmp/bindmounttofoo (which is, in a sense, true).  Hence it decided that the filesystem type of those files was the filesystem type from the mtab line for /tmp/bindmounttofoo, which is "none".

I've now fixed this in 4.2.x (and will soon propagate the fix to 4.3.x).  We take the first match.  I assume that
1. you can't make a bind mount to a filesystem which is not mounted yet,
2. and that you can't unmount a filesystem which is the target of an active bind mount,
3. and that mtab entries appear in the order they were mounted.

If any of the three conditions above is not true, this behaviour will recur.  My understanding of Linux however is that all these properties hold, and indeed breaking (1) or (2)  would make other people very unhappy (as well as making our code stop working).

James.

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 20 Nov 2005 08:54:21 AM UTC, comment #4: 

jay wrote in comment #3

> Is this affected by the fix to bug #14922 ?


Nope, this still applies to 4.2.26.

argenau:/usr/share/doc/findutils# /tmp/findutils-4.2.26/find/find -printf '%F\n' | sort -u
ext3
argenau:/usr/share/doc/findutils# mount -v --bind /tmp /sid/tmp
/tmp on /sid/tmp type none (rw,bind)
argenau:/usr/share/doc/findutils# /tmp/findutils-4.2.26/find/find -printf '%F\n' | sort -u
none
argenau:/usr/share/doc/findutils# /tmp/findutils-4.2.26/find/find --version   
GNU find version 4.2.26
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION

Andreas Metzler <ametzler>
Sat 19 Nov 2005 10:37:39 PM UTC, comment #3: 

Is this affected by the fix to bug #14922 ?

James Youngman <jay>
Project AdministratorIn charge of this item.
Fri 11 Nov 2005 06:15:07 PM UTC, comment #2: 

Jay wrote:

> I don't have support for the relevant filesystem on my development machine either.
> Could you ask the original problem-reporter to investigate further?


As I am the original submitter for this one, I'll try to be as helpful as possible. ;-)

However I doubt that you are really without "support for the relevant filesystem", bind-mounts are a standard Linux kernel feature since iirc 2.4. (See mount(8))

             cu andreas

--------------------
argenau:~# mkdir /tmp/foo /tmp/bindmountoffoo
argenau:~# touch /tmp/foo/bar
argenau:~# ls /tmp/foo /tmp/bindmountoffoo
/tmp/bindmountoffoo:

/tmp/foo:
bar
argenau:~# mount --bind  /tmp/foo /tmp/bindmountoffoo
argenau:~# mount | grep foo
/tmp/foo on /tmp/bindmountoffoo type none (rw,bind)
argenau:~# ls /tmp/foo /tmp/bindmountoffoo
/tmp/bindmountoffoo:
bar

/tmp/foo:
bar

Andreas Metzler <ametzler>
Fri 11 Nov 2005 07:55:45 AM UTC, comment #1: 

I tried to reproduce the problem by just editing /etc/mtab.  

find goes through the file calling stat on the entries.  If the path in the entry has the same device number as the file we're trying to match, find uses the fstype from that line in the file.

This means that if you add an entry to /etc/mtab which isn't really mounted, you can get spurious matches, like I just did.  Hence I can't reproduce the problem just by editing /etc/mtab.  I don't have support for the relevant filesystem on my development machine either. 

Could you ask the original problem-reporter to investigate further?

James.

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 06 Nov 2005 10:22:16 AM UTC, original submission:  

find's filesystem-specific functions break when parts of searched filesystem are bind-mounted somewhere else:

ametzler@argenau:/usr/share/doc/findutils$ find -printf '%F\n' | sort -u
ext3
argenau:~# mount -v /sid/tmp/
/tmp on /sid/tmp type none (rw,bind)
ametzler@argenau:/usr/share/doc/findutils$ find -printf '%F\n' | sort -u
none

cu andreas

Andreas Metzler <ametzler>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #2718:  mtab added by ametzler (378B - application/octet-stream - mtab with bind-mounts)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by ametzler (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2005-12-06 jay Open/ClosedOpen => Closed
        Fixed ReleaseNone => 4.2.27
    2005-11-23 jay StatusNone => Fixed
        Assigned toNone => jay
    2005-11-06 ametzler Attached File- => Added mtab, #3086

    Back to the top


    Powered by Savane 3.5