Re: /var partition seems locked or read only
On Tue, Jul 29, 2014 at 11:08:41AM +0200, berenger.morel@neutralite.org wrote:
>
>
> Le 28.07.2014 22:36, Andrei POPESCU a écrit :
> >On Lu, 28 iul 14, 11:24:31, berenger.morel@neutralite.org wrote:
> >>Le 27.07.2014 01:42, PaulNM a écrit :
> >>
> >>>Inodes are files/folders, files/folders are inodes. (1-to-1)
> >>Anything
> >>>that has a bunch of files/folders will use a bunch of inodes. Same
> >>>number in fact.
> >>
> >>Hum... is it accurate?
> >>Files can use more than one inode, with ln
> >
> >Are you talking about hard links? As far as I understand (but I'm
> >sure
> >someone will correct me if I'm wrong) the file itself is always
> >just one
> >inode, but there are one or more directory entries (links)
> >pointing to
> >it. If you remove all of them the file is deleted.
> >
> >>Folders can not, AFAIK, since
> >>symlinks are simply pointers to inodes (which are themselves
> >>pointers --with
> >>reference counter I guess, std::shared_ptr in c++11?-- to data).
> >>I'm simply asking, I might be completely wrong or inaccurate...
> >
> >Symbolic links, a.k.a. soft links, a.k.a. "symlinks" are files
> >themselves (i.e. each using one inode) that contain a pointer to
> >one of
> >the directory entries of another file or directory.
>
> That was what I thought, yesterday before trying to ask those
> questions. While asking them, I did some quick research, because I
> had doubt.
> What I learned is that the kind of symlinks you speak about, is slow
> (for various reasons. I've discovered that on the French version of
> this article:
> http://en.wikipedia.org/wiki/Symlink#Storage_of_symbolic_links), and
> that there are now another kind of symlinks, much faster, which are
> not files since they do not use clusters: all informations are
> contained in the inode. So, less disk space, and it seems that it
> avoid keeping open more than one inode, which was a problem of the
> file approach.
I think, but not sure, that the situation is more complicated than
either/or :
If the path from the location of the symlink in the file system
is short enough to be contained in the 256char limit of file names,
there is no extra node (and the access to the target file is fast
because one less disk access). But if the path requires cross file
system path, or is to long to fit in a filename slot in a directory,
then another inode is allocated. Or maybe I have made a total botch
of describing what is actually happening. This amounts to a situation
dependent either/or instead of a simple design decision either/or
YMMV or not ;-)
It's hard for me to believe that symlinks could be so numerous as to
exhaust the supply, but maybe if there is a deamon running a script
that assigns synlinks and the script has a bug.
>
> >$ rm testfile
> >$ cat testsl
> >cat: testsl: No such file or directory
> >
> >(the error message is a bit misleading)
>
> From what I have learn recently, it seems that misleading messages
> are common when playing with filesystems outside the classic uses.
>
> >$ file testsl
> >testsl: broken symbolic link to `testfile'
>
> >This should also explain why hard links only work on the same
> >filesystem
> >while symbolic links also work across file systems and why you can
> >delete a file if and only if you have write permissions for the
> >*directory* containing it :)
> >
> >Kind regards,
> >Andrei
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] ad2845b3bef6817278209fcfc1fb643d@neutralite.org">https://lists.debian.org/[🔎] ad2845b3bef6817278209fcfc1fb643d@neutralite.org
>
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: