[opensuse] 'mv' a read-only directory doesn't work...why not?
I had two items in dir 'a', file1 and dir1 (empty) I have full rwx access to 'a' (and am owner): dir a: drwxrwxrwx 3 law lawgroup 29 Nov 9 07:59 ./ dr-xr-xr-x 2 law lawgroup 6 Nov 9 07:25 dir1/ -r--r--r-- 1 law lawgroup 0 Nov 9 07:25 file1 dir b: drwxrwxrwx 2 law lawgroup 6 Nov 9 07:59 ./ try to move everything in 'a' to 'b':
mv a/* b/ mv: cannot move 'a/dir1' to 'b/dir1': Permission denied
I know this is basic unix/linux 101, but I need some review: Permissions of parent allow things to transfer in and out of the parent, right? The settings on file1 and dir1 for 'read-only' should affect the file and the directory, right? So why is moving 'dir1' from 'a' to 'b' disallowed? Shouldn't the move only look at the rw permissions on 'a' and 'b'? To "emphasize the point": 1) I can do a 'cp -a a/dir1 b/' which works. Since they are on the same device, even hardlinks will be duplicated. 2) I can then follow-up with 'rmdir a/dir1', which also works (no warning like when removing a file):
rm a/file1 rm: remove write-protected regular empty file 'a/file1'?
I.e. the exact same actions 'mv' would do if I was copying between devices. So could someone explain why move doesn't use the parent directory permissions? I don't remember this being standard unix behavior...?? FWIW, tested on xfs file system on: 4.19.0-Ish-Van #4 SMP Wed Oct 31 03:59:49 PDT 2018 2.6.31.14-0.8-default #1 SMP 2011-04-06 18:09:24 +0200 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
man 2 rename /EACCES 09.11.2018 19:23, Linda Walsh пишет:
I had two items in dir 'a', file1 and dir1 (empty) I have full rwx access to 'a' (and am owner): dir a: drwxrwxrwx 3 law lawgroup 29 Nov 9 07:59 ./ dr-xr-xr-x 2 law lawgroup 6 Nov 9 07:25 dir1/ -r--r--r-- 1 law lawgroup 0 Nov 9 07:25 file1
dir b: drwxrwxrwx 2 law lawgroup 6 Nov 9 07:59 ./
try to move everything in 'a' to 'b':
mv a/* b/ mv: cannot move 'a/dir1' to 'b/dir1': Permission denied
I know this is basic unix/linux 101, but I need some review:
Permissions of parent allow things to transfer in and out of the parent, right?
The settings on file1 and dir1 for 'read-only' should affect the file and the directory, right?
So why is moving 'dir1' from 'a' to 'b' disallowed? Shouldn't the move only look at the rw permissions on 'a' and 'b'?
To "emphasize the point": 1) I can do a 'cp -a a/dir1 b/' which works. Since they are on the same device, even hardlinks will be duplicated. 2) I can then follow-up with 'rmdir a/dir1', which also works (no warning like when removing a file): > rm a/file1 rm: remove write-protected regular empty file 'a/file1'?
I.e. the exact same actions 'mv' would do if I was copying between devices.
So could someone explain why move doesn't use the parent directory permissions? I don't remember this being standard unix behavior...??
FWIW, tested on xfs file system on: 4.19.0-Ish-Van #4 SMP Wed Oct 31 03:59:49 PDT 2018 2.6.31.14-0.8-default #1 SMP 2011-04-06 18:09:24 +0200
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 09.11.18 um 17:23 schrieb Linda Walsh:
So why is moving 'dir1' from 'a' to 'b' disallowed? Shouldn't the move only look at the rw permissions on 'a' and 'b'?
You created a simple example. In the real world, there might be files and folders of other users (root?) in there. If a directory can't be "written", then you can't modify the files inside (add, remove or modify them). rmdir works because you modify "." (the current folder) which isn't write protected. rm a/file1 shouldn't work. As per the man page, the mv fails because you don't have write permission to update the ".." entry in the directory you try to move. You need to be able to replace ./dir1/.. with the new parent folder but you can't. *EACCES *Write permission is denied for the directory containing /oldpath/ or /newpath/, or, search permission is denied for one of the directories in the path prefix of /oldpath/ or /newpath/, or /oldpath/ is a directory and does not allow write permission (needed to update the /../ entry). (See also path_resolution(7) <http://man7.org/linux/man-pages/man7/path_resolution.7.html>.)
To "emphasize the point": 1) I can do a 'cp -a a/dir1 b/' which works. Since they are on the same device, even hardlinks will be duplicated. 2) I can then follow-up with 'rmdir a/dir1', which also works (no warning like when removing a file): > rm a/file1 rm: remove write-protected regular empty file 'a/file1'?
I.e. the exact same actions 'mv' would do if I was copying between devices.
Err no. The actions have the same result but use different operations. To get to the backside of a house, I can go left and right (and even over the roof). Same result, different ways. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/9/2018 11:10 AM, Aaron Digulla wrote:
To "emphasize the point": 1) I can do a 'cp -a a/dir1 b/' which works. Since they are on the same device, even hardlinks will be duplicated. 2) I can then follow-up with 'rmdir a/dir1', which also works (no warning like when removing a file):
rm a/file1 rm: remove write-protected regular empty file 'a/file1'?
I.e. the exact same actions 'mv' would do if I was copying between devices.
Err no. The actions have the same result but use different operations. To get to the backside of a house, I can go left and right (and even over the roof). Same result, different ways.
---- Except the copy+delete is exactly what 'mv' does when the target is on a different file system. I.e. it could transparently do the same operations when the user asks for a 'mv'. wouldn't be as efficient, but it would mv the read-only directory. Just can't move it directly. To me, that seems a bit strange...like if you make the dir read-only, then you have to use the inefficient form to move it, vs. moving it directly. But if I can't update the '..' entry, that would imply I couldn't rename the parent -- but I can. So why can I update '..' if I rename the parent, but not by moving the child? It seems not only a bit arbitrary, but also pointless, though you do have the "benefit"(?) of losing the original owners and time and date stamps of the directories and files below the top. There's also the fact that I can goto another platform cygwin on win, and rename the directory w/no problem: /tmp> mkdir a /tmp> mkdir a/dir1 /tmp> mkdir b /tmp> mv a/dir1 b/ /tmp> Why, on linux can I rmdir a/dir1, with no problem/warning (where 'dir1' is a read-only dir)? I'd think deleting should generate some permission denied message if only moving it generates one, no? Thanks for response...I guess I'm unhappy with the inconsistencies and arbitrariness. linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/11/18 04:02 PM, Linda Walsh wrote:
On 11/9/2018 11:10 AM, Aaron Digulla wrote:
To "emphasize the point": 1) I can do a 'cp -a a/dir1 b/' which works. Since they are on the same device, even hardlinks will be duplicated. 2) I can then follow-up with 'rmdir a/dir1', which also works (no warning like when removing a file): > rm a/file1 rm: remove write-protected regular empty file 'a/file1'?
I.e. the exact same actions 'mv' would do if I was copying between devices.
Err no. The actions have the same result but use different operations. To get to the backside of a house, I can go left and right (and even over the roof). Same result, different ways.
---- Except the copy+delete is exactly what 'mv' does when the target is on a different file system.
As usual, Linda, spot on. But when on the same device it does a link/unlink. That's an important difference!
Thanks for response...I guess I'm unhappy with the inconsistencies and arbitrariness.
I don't know. The way you present it, it is, and I don;t think it is fair to compare Linux with CygWin. But whenever I've faced this on my machines and I've drilled down step by step I've always found out there was something I was missing, something I was supposing that wasn't so. I can't look over your shoulder for the details; yes AS YOU PRESENT IT it is inconsistent. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/9/2018 1:16 PM, Anton Aylward wrote:
Thanks for response...I guess I'm unhappy with the inconsistencies and arbitrariness.
I don't know. The way you present it, it is, and I don;t think it is fair to compare Linux with CygWin.
They both attempt to provide some posix compatibility. However, the MS case, inodes are kept together in 1 area and content in another, though in a way that is true for linux as well. One thing that has never been clear is what permissions apply to metadata. Clearly things like last access are exempt from a read-only setting on the file. In this case, the read-only setting usually associated with the data and it is the settings on the directory that control access to the file's meta data:
mkdir a; cd a mkdir dir1 touch file1 chmod 000 dir1 file1 llg total 0 d--------- 2 law lawgroup 6 Nov 10 00:57 dir1/ ---------- 1 law lawgroup 0 Nov 10 00:57 file1
All of the metadata is visible. The ".." entry is not user-created content, but meta data of the file system to store a back ref to a parent. I wouldn't automatically believe that such an entry would (or should) forbid moving the directory.
From an administrative viewpoint, I can see the benefit of the current behavior, but from an engineer standpoint, explanations of the behavior seem a bit specious.
But whenever I've faced this on my machines and I've drilled down step by step I've always found out there was something I was missing, something I was supposing that wasn't so.
I present it here so someone might point that out to me, since I don't see it .
I can't look over your shoulder for the details; yes AS YOU PRESENT IT it is inconsistent.
That's why I present all of the details here, so you can look over your own shoulder and see if I am misrepresenting something, should you be so interested. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/11/18 04:10 AM, L A Walsh wrote:
However, the MS case, inodes are kept together in 1 area and content in another, though in a way that is true for linux as well.
Well, yes ... and no. Certainly in the days of the UNIX V6 and V7 file system that was the case; and as I keep complaining, it required preallocation and you could run out of one before the other. The Berkeley Fast File System still had this, but rather than ALL the inodes at the start of the disk, it arraigned them in groups in batches across the disk, but there was still the HARD separation between inodes and data. In theory, a B-tree system can get around that. The ReiserFS certainly does, completely. The ext4FS doesn't; it still has a 'hard divide', the need for preallocation. However it arranges the inodes and the data on b-tree lists, but separate ones. It makes access faster, I suppose. The BtrFS follows the idea of ReiserFS in that there is no division in function inode vs data. It is just blocks allocated off the b-tree list on demand. To the best of my knowledge the IBM derived JFS is like that as well; or at least it acts that way as far as I can tell, I've not looked at the source. I'm led to believe that XFS is also this way, that space is in a b-tree and blocks are handed out on demand and there is no pre-allocation as to inode or data. My experience with XFS is limited, but everything I've read makes it clear that there is a LOT that can be tuned about the size, structure and allocation of the inodes, never mind how XFS interacts with RAID. Some people seem to like fiddling with all this tuning. I don't. So, yes you can configure your file system with the archaic V7 style FS, it's called "sysv", but I can't see a mkfs or a fsck for it. https://www.kernel.org/doc/Documentation/filesystems/sysv-fs.txt The "Berkeley Fast File System" has seen incarnations for SUN, Next, the Amiga and for BSD, but I don't know about Linux. There is a 'ufs' driver, but see the same apprehensions about mkfs and fsck as for 'sysv'. http://www.cse.unsw.edu.au/~cs9242/02/lectures/09-fs/node4.html https://en.wikipedia.org/wiki/Unix_File_System <quote> Linux includes a UFS implementation for binary compatibility at the read level with other Unixes, but since there is no standard implementation for the vendor extensions to UFS, Linux does not have full support for writing to UFS. The native Linux ext2 filesystem was inspired by UFS1 but does not support fragments and there are no plans to implement soft updates.[citation needed] (In some 4.4BSD-derived systems, the UFS layer can use an ext2 layer as a container layer, just as it can use FFS and LFS.) </quote> Personally I view the hard division of inode space and data space on these file systems to be an anachronism and a limitation that faster machines, larger address spaces and particularly good b-tree code has made irrelevant. In addition, given ReiserFS, XFS, BtrFS and JFS and their use of true b-tree pools that make the preallocation of the number of inodes a mkfs issue, ext4 is on a weak footing in this regard; only its excellent performance justifies its use. If there is an ext5 that breaks away from this preallocation model, then it is going to be a horrendous piece of code to do that AND maintain backward compatibility. I suggest using one of ReiserFS, XFS, BtrFS or JFS. -- “Let us not, in the pride of our superior knowledge, turn with contempt from the follies of our predecessors. The study of the errors into which great minds have fallen in the pursuit of truth can never be uninstructive. As the man looks back to the days of his childhood and his youth, and recalls to his mind the strange notions and false opinions that swayed his actions at the time, that he may wonder at them; so should society, for its edification, look back to the opinions which governed ages that fled.” ― Charles MacKay, Extraordinary Popular Delusions and the Madness of Crowds -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/10/2018 6:42 AM, Anton Aylward wrote:
On 10/11/18 04:10 AM, L A Walsh wrote:
However, the MS case, inodes are kept together in 1 area and content in another, though in a way that is true for linux as well.
Well, yes ... and no.
Certainly in the days of the UNIX V6 and V7 file system that was the case; and as I keep complaining, it required preallocation and you could run out of one before the other.
So sorry, I mentioned 'inodes', I should have said 'meta-data'. In both the xfs and ntfs cases the meta-info could be containined in a space roughly equivalent to the inode (ignoring MS's putting them all together in a control block). Now, (vs. 1980) we have xattrs that also include other meta data including privileges and permission controls. The point was that the file permissions generally didn't apply to the metadata and there was (and still is) a *logical* separation. Where you physically put that isn't so relevant as the policies that mediate access to them. Please understand this wasn't about the physical location of inode data, but the separation of meta-data and user-data. To emphasize the point, xfs has a utility (I think ntfs used to have something similar but it didn't dump everything), to just dump the meta-data for a partition (and later allow restoring it) for various uses including backup-media that doesn't store meta-data -- allowing meta-data to be stored as a separate file. Sorry for any confusion. -linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/11/18 11:21 PM, L A Walsh wrote:
So sorry, I mentioned 'inodes', I should have said 'meta-data'.
Could you please clarify how that is different? I do understand that an i-node *can also* carries allocation information.
In both the xfs and ntfs cases the meta-info could be containined in a space roughly equivalent to the inode (ignoring MS's putting them all together in a control block).
MS does have a tendency to use different names for familiar concepts. And, on the other hand, the UNIX/Linux/BSD side calls it an 'i-node' whether it is on disk (possibly in compressed form) or in memory (possibly in uncompressed form with additional links & pointers). There's a trope in SF/world-building: "Call a rabbit a Smerp". It's a exhibition of the "We're in space, so regular old Earth flora and fauna names just won't do.". That the Smerp is a vegetation with big, radar-like ears to sense approaching predators is beside the point ... "We're in MS-land so the regular old <strike>Earth</strike> CompSci <strike>flora</strike> structures and <strike>fauna</strike> names just won't do". if you are going to call an 'inode' a 'control block' then you better illustrate the relevance of the differences for all us Linux-weenies who have never drilled down on MS-internals.
Now, (vs. 1980) we have xattrs that also include other meta data including privileges and permission controls.
Yes, and we also have some file systems specifics, constraints or attributes determined at FSCK time, perhaps. The "i-" is for "Information". Yes, I know it is "obvious" but it gets overlooked.
The point was that the file permissions generally didn't apply to the metadata
If you mean you can run "ls" and see that a file is inaccessible then yes. But then again there are situations where the 'ls' command displays a field of question marks. perhaps the i-node is 'corrupt' or insensible. perhaps it is inaccessible.
and there was (and still is) a *logical* separation.
Yes. But that shouldn't necessitate the 'hard' separation.
Where you physically put that isn't so relevant as the policies that mediate access to them.
I take you point, but it is only relevant when there is 'no significant load'. The fixed division models of inode separation all get into thrashing after significant use does to searching over a fragments fixed array. Now you may say that "performance isn't the issue here", and in an abstract that may be so, but those same limits tend to bring other 'bugs' into the the light, and while they may be true coding bugs, such as off-by-one errors they may also be design concept errors; not necessarily errors in the data structures or data content but in the coding of the algorithm (such as integer vs unsigned) or in the design of the algorithm itself. I've seen all of the above. I've seen all of the above in mature programs and only emerge, as I say, when stressed in just the right way. And I'm sure I'll see that again and again and again through the rest of my life.
Please understand this wasn't about the physical location of inode data, but the separation of meta-data and user-data. To emphasize the point, xfs has a utility (I think ntfs used to have something similar but it didn't dump everything), to just dump the meta-data for a partition (and later allow restoring it) for various uses including backup-media that doesn't store meta-data -- allowing meta-data to be stored as a separate file.
It depends. Perhaps you could detail that. I can see that backing up a file can drop meta-data, or transform it (think: running 'rsync' as root without .... -p, --perms preserve permissions -E, --executability preserve executability -A, --acls preserve ACLs (implies -p) -X, --xattrs preserve extended attributes -o, --owner preserve owner (super-user only) -g, --group preserve group --devices preserve device files (super-user only) --specials preserve special files -D same as --devices --specials -t, --times preserve modification times And that skips over such information as links, symlinks and block sizes) And, SORRY, but I DO think it has to do with "location". The thing about the fixed allocation models of the UNIX V6/V7 (aka SCO or sysv) and the BFFS is not mealy that they are in a specific (and therefore fixed) location of the disk but that they are, therefore, fixed in size. They are not extensible in the way that the B-tree systems are.
Sorry for any confusion. -linda
I think that I'm taking a broader view of this that you are. I can see your point but I keep doing a "yes but..." For example, on-disk data location, block pointers, is part of the data in an i-node under the UNIX/Linux model, but there are file systems (e.g. from IBM) where the i-node-equivalent holding the kind of meta-data about access is a derivative of other 'pointers' ... and so is the storage. Then there are non-file-system storage. The sort of databases where "you don't need to know how they are physically constructed and it might not all be the same" and there is record and field meta-data, access, locking and more. (IBM has a lot to account for!) There's a LOT of "yes, but..." out there. -- "Nothing is more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things." -- Machiavelli -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/11/2018 16:23, Anton Aylward wrote:
On 11/11/18 11:21 PM, L A Walsh wrote:
So sorry, I mentioned 'inodes', I should have said 'meta-data'. Could you please clarify how that is different?
Er, no, hang on. Metadata is a general term. Even the simplest filesystems still around, e.g. FAT16, still have at least some rudimentary metadata -- in the case of FAT, whether a file is hidden, system, read-only or a volume label. More sophisticated filesystems have more or richer metadata. The "i-node" is a Unix concept and relates to the way _Unix_ and Unix-style filesystems are organized, which in turn is connected with the C programming language and C storage. I lack enough low-level knowledge of Unix filesystems to make much in the way of general comments, but inodes != metadata, and metadata != inodes. In Unix FSs, inodes _contain_ (some of) each file's metadata (not including, for example, the file's name, of which it may have several.) Many filesystems do not use inodes at all. ReiserFS doesn't. Other FSes which AFAIK are _not_ inode based include: * ADFS (Acorn, notable RISC OS) * BFS (BeOS, Haiku) * Apple MFS, HFS, HFS+ (OS X, iOS) * HPFS (OS/2) * NTFS * DEC Files-11 * Amiga FFS -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/11/18 11:02 AM, Liam Proven wrote:
Many filesystems do not use inodes at all. ReiserFS doesn't.
That's not a correct statement. What you mean is that if you run 'df -i" on a reiser file system ... $ mount | grep reiser /dev/mapper/vgmain-vHome on /home type reiserfs (rw,nosuid,nodev,relatime,user_xattr) $ df -i /home Filesystem Type Inodes IUsed IFree IUse% Mounted on /dev/mapper/vgmain-vHome reiserfs 0 0 0 - /home Yes, ReiserFS uses i-nodes, but read what I was saying earlier: ReiserFS does not have a preallocated amount of inodes as does the V6/V7/SCO/sysv and the ext2/3/4 file systems do. It allocates inodes *as needed* from the pool of free blocks on the B-tree list, the same pool that it draws from for data. Let me make that clear: ReiserFS stores *EVERYTHING*, metadata ("stat items"), directory entries ("directory items"), inode block lists ("indirect items"), and tails of files ("direct items") in a single, combined B+ tree. By contrast, the other file systems I've mentioned make use of a fixed index principle for finding inodes in a fixed size linear array, hence limiting the number of files they may contain. In addition, such file systems also store directories as simple lists of entries, which makes directory lookups and updates linear time operations and degrades performance on very large directories. ReiserFS avoids both of these problems due to the inherent nature of B+tree scalability. And, as I keep saying, unlike the V6/BV7/SCO/sysv and the ext2/3/4 file systems, it can never run out of one before the other. Three is a price for that. Since there is not a known number of i-nodes preallocated you can't tell what percentage are used. You can't tell how many you had to start with, and to tell how many you have in use you will need to traverse the whole file system tree, counting as you go along. So the "du -i" command is meaningless. Which does *NOT* mean that ReiserFS does not have the information that makes up an I-node on the disk associated with the the file; it just doesn't do it the way other file systems do. But so what? Linux doesn't do a lot of things that OS/360. RSTS and others did, The JFS works differently. There is a separate, dedicated B+ tree for inodes, and the root of that three holds information about what is on that tree, indicating how many of its entries in the i-node are being used and another field describing whether they are leaf nodes or internal nodes for the B+ tree. The tree terms are rather more 'linear' in nature than with ReiserFS and can be copied more directly into memory. If there is no i-node then were is the information about file size, ownership etc held? let's face it, B-tree structures are not like the traditional linear arrays in which 'older' file systems store their inodes. But we are back to the Rabbit/smurf issue. If it is not an i-node then how is it storing the (POSIX required): - The size of the file in bytes - Device ID - User ID of the file - Group ID of the file - The file mode that determines the file type and how the owner, group, and others (world) can access the file - Additional system and user flags to further protect the file (think: xattr) - Timestamps - A link counter that lists how many hard links point to the inode and of course the essential ... - Pointers to the disk blocks that store the file’s contents That it is not stored (on disk* in a predetermined place as as a part of a linear array does not stop it being an i-node. Once it is accessed, what is in memory, in the "inode table", however that may be organized (and I'm not presuming it is a linear array either), then it looks just like the in-memory inode of any other file system. You can bet that when a VFAT file system file is accessed it has an in-memory inode that gets 'mapped' to look like everything else :-) No matter what the "Block" looks like on disk. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/11/2018 18:37, Anton Aylward wrote:
That's not a correct statement.
[Shrug] Take it up with these folks... https://en.wikipedia.org/wiki/Inode "Some Unix-style file systems such as ReiserFS omit an inode table" https://serverfault.com/questions/672645/how-to-increase-inodes-limit-in-rei... "ReiserFS doesn't use inodes." http://www.linux-mag.com/id/8658/ "For example, ReiserFS does not use traditional inodes." -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/11/18 06:02 AM, Liam Proven wrote:
On 12/11/2018 18:37, Anton Aylward wrote:
That's not a correct statement.
[Shrug] Take it up with these folks...
https://en.wikipedia.org/wiki/Inode
"Some Unix-style file systems such as ReiserFS omit an inode table"
To be an absolutely linguist reductionist, yes that is true; a B+ tree list is NOT the same as a table.
https://serverfault.com/questions/672645/how-to-increase-inodes-limit-in-rei...
"ReiserFS doesn't use inodes."
It can't NOT. The information, the 'meta-data', ha to be there, has to be available, otherwise the file could not be accessed. That you can do a 'stat()' on a file on a ReiserFS proves that it is there.
http://www.linux-mag.com/id/8658/
"For example, ReiserFS does not use traditional inodes."
Again, being an absolutely linguist reductionist, I would say that "ReiserFS does not internally represent inodes in a tradition manner". -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/13/2018 3:32 PM, Anton Aylward wrote:
Again, being an absolutely linguist reductionist, I would say that "ReiserFS does not internally represent inodes in a tradition manner".
Is a TV with a screen represented by pictures on a page printed on dead-wood (or similar) that doesn't have moving pictures, but ones that are static, a TV? You miss Liam's point. The inode was/is something specific in unix terminology/technology. It's not a generalizable term for metadata. Metadata has a soft-edge meaning and isn't a technical data structure. An inode is. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/11/2018 01:37, L A Walsh wrote:
You miss Liam's point. The inode was/is something specific in unix terminology/technology. It's not a generalizable term for metadata. Metadata has a soft-edge meaning and isn't a technical data structure. An inode is.
*Thank* you! This is precisely what I was saying. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/11/18 07:37 PM, L A Walsh wrote:
You miss Liam's point. The inode was/is something specific in unix terminology/technology. It's not a generalizable term for metadata. Metadata has a soft-edge meaning and isn't a technical data structure. An inode is.
No I don't miss his point. My point is that it is the same information, no matter how it is stored on the disk, and once it is read in, doing a 'stat()' or 'open()', the representation in core, in the kernel's i-node table, is the same. You might as well say the data isn't the same because it is in a B+ tree rather than an an indexed block where the index is an array in another block. *It is the information that counts, not its representation on disk.* Point in case: no matter how the information is represented on the disk, whatever the file system, as far as the application is concerned the information is one long continuous array of bytes. Whether it is in 512 bytes blocks on disk, 1K (as with early BSD and some experimental V7), 4K blocks, stuffed in the tail end of an inode block, whether it is in an indexed, double indexed or triple indexed list of blocks, whether it is put together from a B-tree or B+ tree list, is IRRELEVANT. *It is the information that counts, not its representation on disk.* And so too with in-odes. ~~~~~~~~~~~~~~~~~~~~~~~~~~ All this came abut because ReiserFS is COMPLETELY B+ Tree based, so there is no pre-allocation of the number of i-nodes and hence the 'df -i' is meaningless. As for JFS, while the actual allocation is dynamic off a tree, there is a limit: <quote src="http://www.softpanorama.org/Internals/Unix_filesystems/jfs.shtml"> The entire JFS volume space is subdivided into allocation groups. Each allocation group contains i-nodes and data blocks. This enables the file system to store i-nodes and their associated data in physical proximity (HPFS uses a very similar technique). The allocation group size varies from 8MB to 64MB and depends on fragment size and number of fragments it contains. <quote> So it is only truly dynamic within an allocation group. Within a group you can run out of one or the other, just like Ext4. But unlike Ext4, you can move to another group ... <quote> An i-node is a logical entity that contains information about a file or directory. .... It should be noted that the number of i-nodes is fixed. It is determined at file system creation time and depends on fragment size (which is user selectable). Users could run out of i-nodes, meaning that they would be unable to create more files even if there was enough free space. In practice this is extremely rare. </quote> The XFS has a similar 'sort of" preallocation and can run out of inodes because of the 'allocation group" approach. particularly with a highly fragmented FS. See https://support.microfocus.com/kb/doc.php?id=7014318 It comes down to two things: * are there the resources for that sort of information? if there is preallocation, ANY kind of preallocation, then that is possible * it is the information that counts, not how it is stored. Some file systems use blocking that allows other things to be stored in the on-disk inode that make up no part of the in-kernel inode table format that is common to all opened/accessed file. E.g. 'extended attributes' with XFS is they are small enough. The XFS inode consists of three parts: the inode core, the data fork, and the optional attribute fork. This is not the "inode traditional to unix terminology". Is it a files metadata? What all this comes down to is that not matter how it is stored on disk, what DOES matter is what gets into the i-node table in the kernel when a file is accessed. THAT is the common point which defines the only generally accepted i-node structure. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Aaron Digulla
-
Andrei Borzenkov
-
Anton Aylward
-
L A Walsh
-
Liam Proven
-
Linda Walsh