On 12/04/2014 05:50 AM, Shriramana Sharma wrote:
[samjnaa:~] mount | grep btrfs
/dev/sdb1 on /run/media/samjnaa/BRIHATII type btrfs
(rw,nosuid,nodev,relatime,space_cache,uhelper=udisks2)
[samjnaa:~] sudo btrfs fi show /run/media/samjnaa/BRIHATII/
Btrfs v3.17+20141103
[samjnaa:~]

But the manpage of btrfs filesystem says that <path> is an acceptable
argument to show, by which I understand to mean the mounted path of
the filesystem (or a subvolume thereof?).

Some problem here?


Mount Point:     /run/media/samjnaa/BRIHATII
Not Mount Point: /run/media/samjnaa/BRIHATII/

The trailing slash turns the mount point into an implicit reference to the dot "." entry inside the mounted directory instead of the mount point itself.

For normal file-system (vnode etc) operations inside the kernel there is no difference.

For system management operations there is a difference. Lots of tools do extra work to hide that difference. Apparently btrfs does not.

It gets even more confusing for root. Fo instance on my laptop with a BTRFS root...

Gust ~ # btrfs fi show /
Label: 'ROOT'  uuid: eca97d32-637d-41cb-914c-659875968b5e
        Total devices 1 FS bytes used 338.53GiB
        devid    1 size 456.45GiB used 351.06GiB path /dev/sda3

Btrfs v3.17.1
Gust ~ # btrfs fi show //
Btrfs v3.17.1
Gust ~ #

But the filesystem operations through the kernel are fine with extra slashes as extra slashes.

Gust ~ # ls -ld /etc
drwxr-xr-x 1 root root 4440 Dec  4 01:10 /etc
Gust ~ # ls -ld //etc
drwxr-xr-x 1 root root 4440 Dec  4 01:10 //etc
Gust ~ # ls -ld /
drwxr-xr-x 1 root root 380 Nov 18 17:35 /
Gust ~ # ls -ld //
drwxr-xr-x 1 root root 380 Nov 18 17:35 //
Gust ~ #


So the first rule of paranoid system management is "press backspace after tab when expanding directory names".

(Note also what the realpath command does, said command ne library being frequently and silently used in some utilities.)
--
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

Reply via email to