Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On Thu 11 Mar 2021 at 16:02:55 (-0400), Cmdte Alpha Tigre Z wrote:
> El jue, 11 mar 2021 a las 14:51, David Wright escribió:
> > Take the case where partition E: contains the users' home
> > directories for users foo and bar. Foo's video collection
> > in E:/foo/Videos/ eventually grows so large that it has to
> > be hived off onto a separate device, F: is assigned to it,
> > and all of Foo's videos are moved there.
> >
> > Now, a file that Bar knew as E:/foo/Videos/cats.mp4, or
> > even ../foo/Videos/cats.mp4, has the new path F:/cats.mp4.
> >
> > Here's how that works differently on unix filesystems:
> >
> > Old scheme:
> > # mount /dev/sdc1 /home
> > ~foo/Videos/cats.mp4 (or ../foo/Videos/cats.mp4).
> >
> > New scheme:
> > # mount /dev/sdc1 /home
> > on which /home/foo/Videos/ has been copied to device /dev/sdd1,
> > and emptied.
> > # mount /dev/sdd1 /home/foo/Videos
> >
> > Now the videos copied to /dev/sdd1 all appear in the same
> > location as they did before, and all the file paths stay
> > the same.
>
> Thanks for your proposition, I didn't understand the usefulness of a
> unified hierarchy until you put that example.
>
> Well, you still have to mount it, don't you? We don't have to delete
> the mount "feature"
> nor the unified hierarchy, instead we could use both approaches.
If you think you need the feature, it might not be too difficult to
set up, say, a directory called /top, which contains links A, B1, etc
pointing to any directory you choose. Symlinks are the normal way to
approach these requirements, and don't require any modifications to
the filesystem.
> Think of E: and F:
> as sdc1 and sdd1, with direct access to those E: and F:.
Take care how you express this. sdc1 and sdd1 *do* give you direct
access to devices, but it's raw, and doesn't go through the filesystem
access methods. Consequently it would be the easiest way to destroy
your files, which is exactly how most users employ it: with dd, to
write one filesystem over another, or to wipe it with /dev/zero or
/dev/urandom.
> (Now that I'm writing this,
> I think we could use E1: and F1:, I find it useful too). Then you
> could write something like:
>
> mount E1: /home
> mount F1: /home/foo/Videos
The point about sdc and sdd is that these names are outside your
control, being chosen by the kernel in ways you may need to learn
about. The only sensible way ahead here is for you to write
filesystem LABELs into the partitions, eg
LABEL=toto06 /home ext4 errors=remount-ro,nofail,noauto,user,exec,suid 0 2
from my own /etc/fstab. (But that still doesn't give you the option of
opening, say, toto06•Videos/dog.mp4, where • is some sensibly chosen
delimiter.)
I'm not familiar with how Windows assigns drive letters, particularly
ones that are meant to be Stable. Nor what happens if two devices
with the same (Stable) name are plugged in simultaneously.
> The boot device could always be An: (with "n" being some number), so
> the system could automatically do: "mount An: /" at boot. If you
> would prefer some
> operating system interoperability, we could use Cn: instead of An:
I don't think you'll gain any interoperability from these
proposed changes to your filesystem. And any hope that you did
have would immediately be destroyed if you used a letter other
than C: to represent the system drive. That's not because it
has to be C:, but because everybody has respected that convention
since its invention. (IOW it's more like the convention that
usr is called usr, and not UlSteR.)
But AIUI you're fighting hard to go backwards. Under the right
circumstances, I am led to believe that you can mount devices
onto directories in Window's NTFS filesystems, thereby avoiding
letters.
> At the end, you have the safe option to write /something/something_else
> on the command line, or F1:/something/something_else at a GUI.
You'd have to sort out the delimiter ":", and the semantics of
a filename F1:something/something_else. (I take it you're familiar
with how the interpretation of F:a\b is distinguished from F:\a\b
in Windows.)
> Please read the following.
>
> El mié, 10 mar 2021 a las 18:25, Stefan Monnier escribió:
> > > (...) To make it more clear, I think it's important to
> > > give (as much as possible) human-chosen names to the disks (for that
> > > reason I use LVM to partition my disks, where I can label my disks and
> > > partitions, although those labels aren't always reflected in the mount
> > > points, so they're not always visible in the actual names of the files
> > > that reside in them).
I, too, label my disk partitions with a LABEL (as seen in the
example above), and a PARTLABEL (Toto-Home), the latter required here
for unlocking the LUKS encryption,
$ sudo udisksctl unlock --block-device /dev/disk/by-partlabel/Toto-Home
because the LABEL is, as yet, hidden by the encryption.
Yes, there are limitations as to which labels are visible and/or
appropriate to use at different times. You can't unlock encryption
by LABEL, and you can't directly reference files by either of
[PART]LABEL. So the choice of mount point can be important.
I use udev to create mount points with appropriate names when I insert
my own removable drives: udev tries, in order, to match properties
(ID_FS_LABEL, ID_FS_UUID, ID_SERIAL_SHORT, ID_PART_ENTRY_NAME,
DEVNAME's basename, and ID_SERIAL) with a directory of filenames,
each of which contains the name I chose for the mount point.
(Sounds complicated, but it's very simple: it has to be fast.)
I don't currently have any use for LVM. It's a complication
I don't need.
> El mié, 10 mar 2021 a las 19:28, Cmdte Alpha Tigre Z escribió:
> > That would depend whether you would prefer sequentially
> > labeled devices or named devices. The better approach would be to use both (...)
>
> We can store names into devices' filesystems. This way, we could use
> e.g. :Foo:/foo/Videos/cats.mp4. The system will assign it F1:, but then
> it could read into the device's filesystem that it is called Foo, so the system
> makes it available as :Foo: If you plug the device into another PC,
> it will still
> be automatically called :Foo:
>
> We could even use USBa1: or HDDb2:, although it looks a bit more complex,
> it adds more information about the device as (I think, I don't
> remember well) sda
> or sdb do.
>
> As you can see, we don't have to use some fixed existing approach,
> everything could be possible, it's a matter of thinking about possibilities,
> and pros and cons.
Hmm, I'm not sure what sort of reply you want. Perhaps:
"Jolly good idea. Let's do that. How long do you think you'll take?
I'll start thinking about how to persuade people to use it. We need
a major existing problem that it solves, and remember that we're up
against an installed base of devices, like TVs, that can use only
FATnn/NTFS/HFS+/EXTn filesystems, so it needs to be completely
compatible¹ with one of those. Finally, whatever changes are made,
they have to be supported so that it'll all work with future kernels."
Perhaps read this, by someone playing around with a filesystem from
the simpler times in the last century.
http://time.to.pullthepl.ug/post/2013/06/24/porting-an-ancient-filesystem-to-modern-linux/
¹ ie the insertions you make should be either invisible to, ignored by,
or untroubling for, an existing filesystem's access methods.
Cheers,
David.
Reply to: