Linus Torvalds Has 'Robust Exchanges' Over Filesystem Suggestion on Linux Kernel Mailing List (theregister.com) 121
Linus Torvalds had "some robust exchanges" on the Linux kernel mailing list with a contributor from Google. The subject was inodes, notes the Register, "which as Red Hat puts it are each 'a unique identifier for a specific piece of metadata on a given filesystem.'"
Inodes have been the subject of debate on the Linux Kernel Mailing list for the last couple of weeks, with Googler Steven Rostedt and Torvalds engaging in some robust exchanges on the matter. In a thread titled, "Have the inodes all for files and directories all be the same," posters noted that inodes may still have a role when using tar to archive files. Torvalds countered that inodes have had their day. "Yes, inode numbers used to be special, and there's history behind it. But we should basically try very hard to walk away from that broken history," he wrote. "An inode number just isn't a unique descriptor any more. We're not living in the 1970s, and filesystems have changed." But debate on inodes continued. Rostedt eventually suggested that inodes should all have unique numbers...
In response... Torvalds opened: "Stop making things more complicated than they need to be." Then he got a bit shouty. "And dammit, STOP COPYING VFS LAYER FUNCTIONS. It was a bad idea last time, it's a horribly bad idea this time too. I'm not taking this kind of crap." Torvalds's main criticism of Rostedt's approach is that the Google dev didn't fully understand the subject matter — which Rostedt later acknowledged.
"An inode number just isn't a unique descriptor any more," Torvalds wrote at one point.
"We're not living in the 1970s, and filesystems have changed."
In response... Torvalds opened: "Stop making things more complicated than they need to be." Then he got a bit shouty. "And dammit, STOP COPYING VFS LAYER FUNCTIONS. It was a bad idea last time, it's a horribly bad idea this time too. I'm not taking this kind of crap." Torvalds's main criticism of Rostedt's approach is that the Google dev didn't fully understand the subject matter — which Rostedt later acknowledged.
"An inode number just isn't a unique descriptor any more," Torvalds wrote at one point.
"We're not living in the 1970s, and filesystems have changed."
Content (Score:2)
Re: (Score:2)
Re:Content (Score:5, Insightful)
>Linus is a throwback to an era where feelings didn't matter.
Feelings don't change the quality of coding, and sometimes when you waste time trying to avoid hurting feelings you don't accomplish your goal.
Sometimes, someone who is ignorant and has brought up an old already-beaten-into-the-ground argument yet again needs to be shamed or embarrassed in a public forum so not only do they shut up, anyone else thinking of bringing up the argument who sees it is preemptively silenced as well and work can progress.
It's not particularly nice, but it's true.
Re: (Score:2, Insightful)
You may be right, but it's also hard to deny that the development of Linux has been compromised by socially incompetent members of the community whose chief joy seems to be ridiculing and disparaging others.
Re:Content (Score:5, Insightful)
There are situations where a bit of yelling does wonders, and there are situations where it just means you're an arse.
The trick is knowing when to do it, and when to abstain. That's difficult to master.
Re: (Score:3)
I'm a software developer based in South America. And I often get to work with young developers from Europe. In general, the experience seems pretty OK with spanish and portuguese, and becomes worse the closer you get to central europe. The experience with south american devs has always been very positive.
I like to attribute the problem to sheltering first-world societies. People living in countries where kids don't learn at a young age (their teens and 20s) that words out of place do have physical consequen
Re: (Score:2)
It's a matter of culture. My current client is German, and the main devops guy uses strong words and pulls no punches. I like that, a lot. It's a method that yields results. others from my team are kind of scared of him, however I get along with the guy very well.
How one sees that behavior depends on a lot of factors: education style, upbringing, etc.
Re: Content (Score:2)
"If you have problems with everyone, the problem isn't everyone, it's you".
In the end, the company had to remove one of the contractors for repeatedly using unnecessarily harsh language. He was tolerated by (slightly less) toxic coworkers but the rest of the team found this guy was not worth it.
The problem is that we're a senior team. everyone has a lot of experience. there is very little chance that you as an individual can contribute more than the people you're annoying. he got under enough people's skin
Re: (Score:2)
I believe we are talking about two different things :)
Re: (Score:2)
Re:Content (Score:4, Insightful)
Oh? What evidence do you have that the development has been compromised?
Potentially chasing away people who can't be bothered to understand the topic they're arguing about compromises nothing, and greatly reduces the amount of time people who actually understand the subject have to waste arguing against it *again* - which increases the amount of time they can spend doing something useful.
Some people genuinely bring negative net value to the table. And the greater the expertise at the table, the easier that is to do. Especially if it's not shown proper respect by people who lack it. If such people leave, both quality and productivity improves.
Re: (Score:2)
Oh? What evidence do you have that the development has been compromised?
The person who did a huge amount of the USB work, and got Linux USB3 support before any other operating system quit Linux development because of the toxic bullshit on the LKML. The person who developed a load of the power management stuff and UEFI support distanced themselves because of all the toxic bullshit on the LKML.
Even Linus realised his behaviour is not good, apologised for it and has actually worked hard on being better.
Re: (Score:2)
Re: (Score:2)
Yeah and denial isn't just a river in Africa.
Linus knows it was a real problem and accepted a code of conduct. The changes that need to happen are happening whether you think the case is proven or not.
Also, good job on ignoring the USB work.
Re: (Score:2)
I was going to respond, but serviscope_minor did an excellent job. I might only add that in a "general attitude" way, your comment illustrates my point nicely.
Re: Content (Score:3)
I'd say that Google as an organization has been generally compromising the quality of open-source infrastructure by making their sub-par engineers contribute to every single project after brainwashing them that they're the best and that the Google way is the only valid way.
Re: (Score:2)
Re: (Score:2)
For the record, I have had terse and harsh conversations directed at me and I may have felt b
Re: (Score:2)
I've learned to try and look past the "harsh language" as often I work in international teams and none of us are native english speakers. The first thing you lose when speaking a different language is nuance. I've found that "jumping into a call" always makes the other party "nicer". Either they're just terrible at conveying their thoughts in words, or they are just too scared to "look you in the eye" and say "harsh" things.
That said, we had this one guy in the team who had to be removed because even though
Re:Content (Score:5, Insightful)
Re:Content (Score:4, Funny)
>"Feelings do not belong to software development anyway. Not in the past nor now."
Yep. Now tell that to the people with their panties all tied up about "master" and "slave" words in code.
Re: (Score:3)
Linus is a throwback to an era where feelings didn't matter. Back when Bill Gates was yelling at employees and waiters asked if you wanted to sit in the smoking or non-smoking section?
Those aren't examples of "feelings not mattering".
The first is an example of a time when CEOs weren't accountable to anyone and could do anything they wanted without fear of repercussions... except for lost money, of course.
The second is an example of when personal comfort WAS starting to matter. You should have gone back further - to the time before there were non-smoking sections in restaurants at all.
Re:Content (Score:4, Insightful)
Feelings have always mattered, but not in the way you think. Evolution and/or God, pick your poison, did not give them to us without a reason.
Feelings are a means of communication, between people, between people and the world, and within oneself too. They are most userful as feedback. If you get good feelings, you are probably, but not necessarily, doing something right or good; if you get bad feelings, you are probably, but not necessarily, doing something wrong or bad. This feedback exists to draw your attention, make you reflect on your actions and improve on them, if needed.
The way feelings are tried to be made matter these days is to see them as meaningless and devoid of useful information, and as such, bad feelings will obviously mean meaningless suffering imposed by other people, who are obviously evil, because why else would they impose this suffering on you. Which is about as userful as calling a hot iron evil because it keeps burning you every time you touch it. Maybe it's trying to tell you to stop touching it, maybe you should listen so you might improve on your current life experience. Because in the end it's not the iron, that is giving you the pain sensation, it's your own body, with your own interests in mind.
If your self-composure is on a level where getting CAPS LOCKed at is too much for you to handle, you have a lot of work to do on yourself, and that's all the news there is in that. And I'm not implying here that the dev in TFA was like that, but I do get a reading that you would consider it normal if he was. But the reality is that if you are like that, you need to revisit your toddler years, because a human being is developed enough to learn to handle basic unpleasant feelings without melting down by the age of four. The fact that we have an epidemic of people who cannot do that means that we in fact have an epidemic of people whose psychological development has not yet reached that age. And there is only so many Karens you have to withess to realize that indeed, these people are toddlers, acting out toddler things.
Which is a really sorry state of things, but the way to address this is not to ban giving people feelings. If the parents of all of these people did not do their job, it is now the job of these people themselves to grow themselves up and understand that they actually want all of this feedback. Because while it is not always pleasant, it is much better to have the early opportunity to fix your problem, than to have it blow up in your face sooner or later. Even if the Karen does not get themself maced or killed in the friendly US society, they are still living away their life in self-inflicted misery, opting for the worst possible outcome in every social situation.
Excues me too for talking about Karens so much, but the thing is, they are an extreme example that gets the point home easily. It is a trivial excercise to understand from that that for people with less extreme emotional regulation problems, their resulting problems will probably be less extreme also, but of the same nature nevertheless.
Now for the Torvalds situation in TFA. The way you go about getting people to stop doing what you do not want them to do is to start easy and escalate until they stop. They can at any moment take the message and avoid the escalation; if one is not sharp enough to get the message on a lower escalation level, there really is no way to get to them but with a higher level of escalation. Which is exactly what happened, and not at all in a dramatic way at that. Imagine this - if the dev does not stop wasting others time, this escalation might in the extreme reach the horrors of CAPS LOCK! Indeed the dev admitted later that they did not know what they were talking about. Problem solved.
Also, does anybody consider Torvalds' feelings here? How would you feel if your time was wasted by stubborn incompetence like that? Thousands of people are directly dependent on Torvalds being able to do his work, and literally billions of people depend on the work of thes
Re: (Score:2)
Re: (Score:3, Insightful)
The inode concept was introduced when physical media was fairly small and it was fairly easy to predict and provide for the maximum likely number of files on that file system. Although the data structure was limited in various ways and subject to disruption (fsck it) it just isn't practical for the multi-petabyte file systems that are appearing more often these days.
It has served us well many years, but the $5,000 10MB hard drive just isn't something we buy anymore.
I don't know what the preferred solut
Re: (Score:3, Insightful)
You've managed to conflate identifiers with data structures more successfully than the quotes have and contributed nothing to resolving that confusion. But sure, "fixed-sized tables" don't seem like a "preferred solution", not that anyone suggested otherwise or even defined what the "solution" would solve.
"It has served us well many years, but the $5,000 10MB hard drive just isn't something we buy anymore."
Nor was it anything we bought when Linux was conceived. And "inodes" aren't a Linux creation. This
Re: (Score:3)
Re: (Score:3)
From what I understand, the underlying issue is that some pseudo-fs don't behave like "real" filesystems in all respects, causing some operations to not function properly, like trying to tar the files or performing some forms of copy.
So there seems to be some effort in trying to make these pseudo-fs "technically" behave like real filesystems in those scenarios, but by doing that the code would become more complex and Linus' issue is that it's worthless complexity, since trying to tar or copy those pseudo-fs
Re: (Score:3)
Yikes (Score:2)
Re: (Score:2)
Even then iirc some networked filesystems like Samba might not even expose inode information. Dunno if Linux makes up inode numbers from pathnames or it's just the same? (I remember reading about it being a contentious issue back in the day to allow Samba mounts due to the lack of inode numbers, I guess the tide has turned since)
Re: (Score:2)
This is Slashdot - what is an article?
I had considered this but dismissed it because I didn't think applications did anything with inodes due to the exact reason mentioned. While it may be more efficient for an application to work with inodes directly, there are many reasons that can get you into trouble and your safest bet is to work with the path. Then again, the path can change if a device is mounted to a different location later. For
Re: (Score:2)
Multiple backup systems (including tar) do this.
Re: (Score:2)
Re: (Score:2)
st_ino, and st_dev in the POSIX stat structure, which say they, together, uniquely identify a file on the system.
st_ino is the file serial number. Also known as the inode.
Re: (Score:2)
Re: (Score:2)
That's not an inode.
Yes, it is.
An inode is the data structure containing file data or directory metadata.
You're confusing implementation with specification.
inodes are an opaque reference. They may refer to a data structure, they may not.
Its arranged in a b-tree usually.
Shut up. You don't even know what the fuck a b-tree is.
st_ino is the inode ID.
lol. No. That's why it's not called "inode ID".
that's why the ino_t type isn't a struct.
Also, this only works on certain filesystems, not them all.
No, it works on them all, except for the one in question. /dev, /sys/, /proc, any tmpfs (/dev/shm/ is a common one)
network filesystem.
Check
All of them.
There's a reason for this:
The POSIX specification demands it.
Re:Yikes (Score:5, Informative)
The discussion in question is purely about virtual filesystems like /proc and /sys, where inodes don't really exist or matter (you already can't just tar up those filesystems, so unique inodes don't matter). The reason Linus got hot is that the same person keeps making broken code submissions to "fix" something that is not a problem (and instead making more problems in the process), and has so far apparently mostly ignored the more gentle approach.
On the other hand, someone else has been working on another virtual FS, and he and Linus (and Al Viro, the lead VFS dev) have had a long back and forth and productive discussion about issues and how to fix them.
If you do your homework on how to integrate with the existing systems, can describe what you are doing, and take productive feedback, Linus and most of the other kernel developers are just fine to work with. This is not "news", this is somebody looking to MAKE news of "see Linus is a bad person!" because someone else repeatedly poked him until he got mad.
Re: (Score:2)
Re: (Score:2)
The particular filesystem in question, probably not, but
And as long as we're on this bone-dead line of reasoning, what about tmpfs?
Linux is being a fuckwit, here. It's rare, but he does it on occasion. He's proposing breaking his own rule- which is don't break userspace. To accommodate all the ways userspace has come up with to get around deficiencies in POSIX.
Re: (Score:2)
Re: (Score:2)
inodes are part of the POSIX contract.
st_ino and st_dev uniquely identify a dentry in a specific filesystem. They, together (and with i_generation in Linux) constitute the File Serial Number.
Re: (Score:2)
You might want to look at the work done on Nilfs2 in this area. It never hurts to know what others have learned, whether or not you pursue a similar approach.
It's also worth considering, given your goal. Nilfs2 is widely available and used, and has been for some time. I don't know Linus' feelings towards it, but they haven't stopped it being popular.
Re: (Score:2)
Not In a Regular FS (Score:5, Informative)
Re: (Score:3)
However it seems to me he is only rude in cases where polite already failed, and once again he proves that rude works in those cases.
How many times do you have to politely decline what is basically the same PR as the last one declined? The PRs dont stop with polite. They stop with rude.
Re: (Score:2)
Oh, context that changes the entire ordinary interpretation of the conversation!
TYFYS.
Re: (Score:2)
where the sematics of inode is very much different, if meaningful at all.
I disagree entirely, and so does every linux archiver I know of.
Note, from an implementation standpoint, tmpfs is as pseudo as the others. It has no actual block backend, and simply forwards requests upstream to the VFS.
Inodes are entirely synthetic, and meaningful.
Re: (Score:2)
I have read the LKML thread, and Linus is wrong for 2 reasons.
One- st_ino, and st_dev are specified by POSIX to uniquely identify a file on a system.
This is why tar et al use them. They're not being used stupidly, they being used according to the POSIX standard.
Second, this deviation from POSIX would come with major userspace breakage, which has long been against the rules in the kernel.
Most likely here, Linus was drunk, and was either not aware of the POSIX specification, or momentar
Re: (Score:2)
It is pragmatism vs blind adherence to standards.
False dichotomy.
It is not pragmatic to meaninglessly deviate from the standard.
It has long been the policy of the kernel that strict adherence to POSIX isn't required at all- but breaking userspace is a no-no. Calling userspace stupid because userspace conforms to a standard the kernel did in this regard is not stupid.
I have never seen a valid case for archiving procfs, sysfs, debugfs, or anything else of their kind.
Not really relevant. You don't get to choose what other peoples' "valid" use cases are.
In this instance, I don't think you understand exactly what you're saying though.
tmpfs works just as
Re: (Score:2)
The dichotomy is true, with the emphasis on `blind' (i.e. without clear understanding why following a certain requirement of a particular standard has any merit).
OK, fair-
In that case, it's just not relevant, because nobody is blindly adhering to the standard.
Only Linus is advocating for blindly breaking it.
My last question is absolutely serious. As Heraclites put it, No man ever steps in the same river twice. The state of a running kernel is ever-changing. How do you define a good copy of, say, procfs?
Ask someone who does such a thing.
Putting tmpfs in the same bag is wrong because the kernel never initiates changes in files stored there, user space does, hopefully on the user's command.
It's not wrong, because from an implementation standpoint- they are identical.
It's true that their use cases are different, but making them behave differently is actually complicating the kernel, not simplifying it.
There is no need to invent use cases, they must be natural: I need to save the files that I edited; I need to save files that a friend sent me; I need to save the toolchain's output so I will not have to rebuild from source. Think of a sane, natural case of archiving eventfs.
Nobody is inventing a use case. You, and Linus, are blindly assuming that you can forsee all existing use cases,
Re: (Score:2)
*wiser than Linus.
Sigh. I really need to proof-read.
Linus wants to start messing w/ the filesystem? (Score:4, Funny)
Who does he think he is - Poettering?
Who does he think he is - Poettering? (Score:2)
No. He thinks he's Hans Reiser. Careful what you say to him on the mailing list, or you'll disappear too.
Re: (Score:2)
You'd have to marry him first.
Re: (Score:2)
I do like Linux... but I'm not THAT committed!
Hardlinks (Score:2)
Isn't a filesystem-wide unique Inode ID required to implement hardlinks?
As in, any two files with the same Inode ID, size, and a hard link count greater than 1 must be hardlinks of each other if they are on the same mounted partition.
Re: (Score:2)
It gets complicated if you have a file system that supports snap shot volumes. At the low-level the answer is no to unique inodes.
Re: (Score:2)
The point here is, that a certain behavior has been taken for granted for ages by userspace, and no real replacement is offered.
Linus is calling what tar does stupid because he has dug himself a hole he can't get out of. There is no good way to identify hard-links without a filesystem unique identifier.
Re: (Score:2)
Re: (Score:2)
TAR is not a compression tool, it is a tool to stream a series of files to another stream. Capturing that stream to a file just happens to be one possible way to use TAR. It can also be used as a hardlink-preserving file copy command when used with pipes. Can even pipe it through netcat and now it's a way to transfer files over a network.
But it's horrible for creating archive files. No seeking support, need to stream through the whole archive file (possibly skipping through the data if the TAR file is n
Re: (Score:2)
The real advantage to tar, is merely that it conforms to specifications. You can generally re-create any thing you may find on a POSIX compliant filesystem with it. Could a better format do that job? Definitely. I think we're all still waiting for that, though.
Re: (Score:2)
Re: (Score:2)
There is no POSIX inode table- inode is merely a synonym for file serial number in POSIX.
Now shut the fuck off, and scamper back into your bullshit-filled basement.
Re: (Score:2)
Isn't a filesystem-wide unique Inode ID required to implement hardlinks?
To implement, no. To use them with any kind of fucking rationality from userspace, yes.
Re: (Score:2)
Re: (Score:2)
Maybe you want to back up files and maintain the hardlinks.
Or maybe you want to know if writing to one file will modify another file.
Your tool for creating hardlinks is a userspace tool.
Re: (Score:2)
Why do you need to use them at all?
Ok, toolshed. You clearly have no fucking idea what you are talking about here.
st_ino, st_dev, and st_nlink in struct stat is why.
These aren't magic numbers from the filesystem. They can be sequential, they can be whatever you want- they just must be unique per mountpoint. POSIX doesn't guarantee that an inode will forever stay the same. It merely guarantees that st_dev + st_ino can uniquely identify a file.
Yeah good editing (Score:2)
Thanks for the insight into the kernel dev process. It's always super interesting!
Leadership at work (Score:5, Informative)
We heard like like unique numbers (Score:2)
Rostedt eventually suggested that inodes should all have unique numbers...
As I understand it inodes are themselves are supposed to be unique numbers. How would adding a second unique number to that already-unique number make things better?
"Yo dawg, we heard like like unique numbers, like inodes, so we added a unique number to your unique number."
Re: (Score:2)
Unique numbers are not always trivial.
You can choose huge random numbers, so the probability of collision is close to 0, but huge random numbers are easy on a PC, not necessarily so easy on some random ARM device with a crappy ring oscillator RNG. Linux runs on many things. Also big random numbers are, well, big. So take up space. I don't think inodes IDs are 256 bits or more. The internet tells me they are 32 bits. So not nearly big enough for a globally unique identifier. Maybe big enough for a locally un
Do "st_ino" and "st_dev" uniquely identify a file? (Score:1)
If Linux inode numbers aren't unique, then what does this mean for using the "st_ino" and "st_dev" members of a "struct stat" in the POSIX/X-Open standard to uniquely identify a file?
Re: (Score:2)
In the original context of the suggestion, it was about breaking that behavior specifically in the context of eventfs, not a "real" filesystem.
It did seem to suggest that btrfs also breaks that behavior with mounted snapshots too... Of course, this scenario gets tricky, one could imagine that a snapshot *should* by all rights be able to have an indepedent set of inodes, but if it's a filesystem construct without a distinct device, then that seems awkward, since you would expect to map st_dev to a devnode,
Linus style is not subject to debate (Score:4, Insightful)
If you don't like what Sony does, don't buy Sony. If you don't like what Linux does, don't use Linux. If you don't like how Linus Torvalds expresses himself, don't engage with him. Each "tool" has its use, purpose, cost, and downsides. I happen to like his style, as do other coders. Some puff pastries are offended, and some call him a relic. Be that as it may nobody forces you to buy Elon Musk's Tesla or Steve "I stole a liver" Jobs' iPhone or Linus' "Shut the hell up" Torvalds or Kimi "I know what I'm doing" Raikonnen's driving.
Onto Inodes. The original article didn't go into it, so I will. Consider this a shortened layman's version so as not to confuse the puff pastries upset that Linus has a brain AND a mouth.
Inodes are data. They are structured in a way that allows matching up some part of other data (e.g. files) with some part of other data (e.g. who owns the files, who is allowed to access them, for what purposes, creation time, etc.) This makes inodes "metadata" which is "data about other data." People like to say "Oh it's metadata" as if that makes some difference. It does not. It's data, and like all nongarbage data, has some purpose.
An inode may contain a unique identifier. It's not required, and in some filesystems isn't even an option. A lightweight file system doesn't need the inode to be independently tracked, cataloged, nor identified. Its purpose can be met so long as its association with the right data object(s) is(are) maintained.
There is no question that there IS DEFINITELY A NEED to maintain information ABOUT files in a filesystem. At the very least, the location of the contents and an association with a 'handle' (which can be abstracted into "filename" or "path") are necessary for simple human interaction. If humans didn't have to list a directory contents ('ls') or view a folder then the whole concept of the 'handle' becomes something which may not be comprehensible to humans. Examples of this about in the various cache directories (such as Google-Chrome's cache, Firefox's cache, etc.) and the abstraction is a very long hexadecimal string.
Given that there are many filesystem types, some physical, some virtual, some simple, some layered, and each has its strengths and weaknesses*, the global concept of inode in Linux is a matter of discussion. That's what's occurring here. Linus has his opinions, colored by decades of experience, some of which comes from reviewing proposals that never made it into Linux, others in watching evolution of various metadata storage mechanisms. Google hires great people (Hi Bruce!) so there's no doubt some of them are fantastic filesystem concepts people, but ... not... all of them are.
You want to take sides on this one? It's a free country. Take a side. Before you judge someone's style, think to yourself "Would I rather Linus was bold in his statements and kept cruft out of the kernel" or "Would I rather some idiot was 'Dictator for a day' and messed up the kernel so badly nobody could fix it."
E
* I've gone out of my way to leave out discussions of filesystem weaknesses that aren't in the filesystem itself, but are about the actions of the eponymous developer.
The preferable tech career (Score:2)
Not fit to weigh in on this one, only to comment that a lot of people might envy having those same engineering problems that first engaged you in school, still your reason to tear-hair decades on in the career.
Linus is actually farther along in his career arc than the pond scum that had to go apologize to Congress for their products this week; an apology cheerfully given, as it was not just cheap, but free. Congress has no intention of actually legislating or regulating away their oligopoly and their freed
Sitcom? (Score:2)
Very weird.. (Score:2)
At one point, Linux hat a tirade that the kernel should never ever break userspace. Which I appreciated.
Then someone birngs up that tar and find break if inodes are funky, and Linux counters that the real problem is "tar does stupid things".
While the original context was inodes in the context of a pseduo filesystem in which case I'd tend to understand the "no meanigingful indoes" scenario, but the tar example cited was traversing into snapshots, which tar would do when snapshot access looks like just anothe
Re: (Score:2)
tar, and every linux archiver I'm aware of uses inodes to detect hard-links. This is a problem on btrfs snapshot subvolumes, as you mentioned, but in that case, it can at least be detected and treated like another mount.
The idea the userspace doesn't need inodes, and only jackasses use them is wrongheaded. Linus is wrong. It happens.
Re: (Score:2)
Re: (Score:2)
You don't implement a new fucking kernel interface to do the job of an existing POSIX interface- that's quite literally against the standing rules of the kernel. Stop talking out of your ass.
Re: (Score:2)
Re: (Score:2)
Why the fuck do you say a thing when you obviously have no idea what the fuck you're talking about?
Re: (Score:2)
What needs to happen is if detecting hard-links is so important, then there needs to be a function all FSes implement that tells you if a path is a hard or soft link. Then the tools just use that rather than reaching into internal data structures that are implementation specific. This would clean up all of these issues in a clean way that reduces bug count significantly. He understands there is a leaky abstraction here that is a bug farm. Just because compression tools do this, doesn't make it right.
Well that is specified already:
Identifies the device containing the file. The st_ino and st_dev, taken together, uniquely identify the file. The st_dev value is not necessarily consistent across reboots or system crashes, however.
Per glibc documentation of the POSIX defined attirbutes st_ino and st_dev. So technically there is a mechanism: the combination of backing device and the filesystem curated inode.
This is not reaching into implementation specific data structures, this is following the specification in terms of how files are explicitly declared to behave.
If anything, it would make sense for filesystems wishing to opt out of meaningful inodes to report back some newly dubbed 'special' value. Giv
Filesystems on Linux (Score:2)
There's a huge range of filesystems now on Linux, although some are poorly maintained and are being dropped, which is a shame.
This makes Linux an ideal target for people to experiment with crazy schemes, because they can do a like-for-like comparison with a truly wonderous range of approaches.
Instead of talking on the list, if he has a good idea, he should try it out. Talk is cheap, benchmarks and robustness are the true measure.
Duplication of functionality isn't an issue if the idea is sound and proves its
Re: (Score:3)
That touches a key element which many people seem to overlook. In this type of kernel development, correctness rules above all else. If something is incorrect, especially if it violates the contracts of the operating system or potentially loses data, the harsh lesson will follow.
Linus has absolutely had serious problems with being a jerk in his reactions, but the topics he is triggered by are nearly always about correctness.
Prove that it works, have data to back it up, be able to prove that the behavior
"Robust excahnge" (Score:2)
Which has mode f-words per sentence, "Robust Exchange" or "Animated conversation" ?
Re: (Score:2)
I read the article and I did not understand the meaning of An inode number just isn't a unique descriptor any more. We're not living in the 1970s, and filesystems have changed.".
That tends to mean to me Linux wants to do away with inodes. Is that a correct assumption ? If so, I think that could create lots of porting issues. If that is correct, what will replace it, the same thing Windows uses ?
Re: (Score:2)
Not inodes themselves, but UNIQUE inode numbers in the case of a synthetic filesystem.
Note that inode numbers have never been unique across filesystems and in the case of BTRFS, across sub-volumes.
Re: (Score:1)
In a thread titled, "eventfs: Have the inodes all for files and directories all be the same,"
FTFY
Slashdot, stop trying to confuse us by leaving out words.
Re: (Score:1)
Ok, so the article itself left out that word (on purpose? clickbait? bad journalism?).
But slashdot editors should notice that and call it out with an editorial fix/comment.
Re: (Score:2)
Eventfs is a synthetic filesystem. Indeed, Linus doesn't believe inode numbers need to be unique within eventfs.
Linus is correct here (Score:3)
In the real world, sysadmins should understand that they do not want to tar up pseudo-filesystems contents, and the other p
Re: (Score:2)
Re: (Score:2)
Note that inode numbers have never been unique across filesystems and in the case of BTRFS, across sub-volumes.
Of course. For example, each filesystem root directory on my system has an inode of 2 on the ext4 filesystems, and 34 on the zfs mountpoints. (I thought it was 1, but maybe that's me thinking of something outside of Linux? For Linux, after looking it up, ext2/3/4 use inode 1 to store bad block data. Interesting.)
But if you combine "device" and "inode", that's always been a unique identifier for each file, at least on "traditional" filesystems, and a lot of utilities do rely on this.
For example, changing
Re: (Score:2)
BTRFS behaves very similarly. People get in to the weeds when they mis-think of subvolumes as fancy directories and place them somewhere in some other subvolume's tree. Then they wonder why two "directories" have the same inode number. The ability to descend into a subvolume like a directory is ONLY a nice semantic convenience. It isn't a problem if you create subvolumes in the root volume and mount them into place as intended.
Certainly, running tar across subvolumes-as-directories isn't a great idea.
As for
Re: (Score:3)
I went and read the email threads.
THEY are specifically talking about eventFS, a FUSE based virtual filesystem. Torvalds is promoting the idea that eventFS remain as simple and lean as possible, yet this Google guy comes along, copies code from other virtaul filesystems that he doesnt understand and claims that eventFS needs uniqie inodes so that tar anfd find will work.
Torvalds argues that doing so is insane, as there is no reason a virtual filesystem like eventFS needs extra complications. EventFS is li
Re: (Score:2)
Thank you so much for reading it in depth and provide a layman comprehensive summary of the issue.
Re: (Score:2, Offtopic)
The funny thing about the permanently outraged is, well, let's just focus on:
2. Add a sensitivity checker for killing applications. Ensure a fair and equitable distribution of SIGKILL signals across all applications.
It has one, it's called the OOM killer.
3. Prevent any application from amassing large memory footprint and share resources according to the needs.
That's called variously, ulimit, nice which it inherited from unix and more recently cgroups.
Also what's really going to make you hate everything is
Re: (Score:2)
Whether or not a filesystem has a concept of inodes in its actual storage structures is separate from the immutable fact that the filesystem does in fact give you unique-per-bdev inodes, which every filesystem does.