Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
El jue, 11 mar 2021 a las 14:51, David Wright
(<deblis@lionunicorn.co.uk>) 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.
Think of E: and F:
as sdc1 and sdd1, with direct access to those E: and F:. (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 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:
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.
Please read the following.
El mié, 10 mar 2021 a las 18:25, Stefan Monnier
(<monnier@iro.umontreal.ca>) 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).
El mié, 10 mar 2021 a las 19:28, Cmdte Alpha Tigre Z
(<santiagopinth@gmail.com>) 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.
--
Time zone: GMT-4
Months: Ene = Jan ; Abr = Apr ; Ago = Aug ; Dic = Dec
Reply to: