Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is it time to remove reiserfs?

lkml.org

Post reply on HN
Print view View original

71–80 of 260 posts

Re: Is it time to remove reiserfs?

#71

Post by michael1999 »

marginalia_nu wrote: post #60
cormacrelf wrote: post #53

Earlier quoted context omitted.

Try the web server Redbean. You put it all in a single zip file, serving a file simply copies the pre-gzipped content directly into a tcp stream. Obviously some of the FS read performance cost is moved into navigating the zip file, but the storage overhead is not, and nor is the read+write-able nature of the FS.

Do zip files really offer performant random access with tens of millions of entries?

I don't see why they wouldn't as long as the TOC (i.e. filenames + headers) fits in ram. The offsets are all there for a simple seek.

Re: Is it time to remove reiserfs?

#72

Post by actionfromafar »

sterwill wrote: post #61
Syonyk wrote: post #51

Earlier quoted context omitted.

It's great for small files, but it's also got some really nasty little corner cases. You do not store ReiserFS filesystem images on ReiserFS filesystems without encryption, or the next time you run fsck, you'll end up with the two filesystems oddly merged into something entirely useless. I'm not sure if that's been fixed, I got a bit tired of the exotica for general daily driver systems, and ext3/ext4 cover my needs…

That's one heck of an edge case! How does fsck manage to completely confuse filesystem metadata and data like this? Surely this is only if there's corruption in the (outer) filesystem, right?

No, the meta-data is somehow distributed and fsck can pick up pieces of it. I don't think you have to encrypt the image to avoid the edge case, a compress of the image should be enough. It still sucks though.

Re: Is it time to remove reiserfs?

#73

Post by fredoralive »

tombert wrote: post #42

Maybe someone with more understanding of kernel development could explain things to me. Does there have to be explicit kernel-level support to support a filesystem? Even if they remove support, does that stop anyone from releasing a kernel module and supporting it?

You can implement filesystems as a kernel module, or use a filesystem-in-userspace option.

Re: Is it time to remove reiserfs?

#74

Post by Piskvorrr »

tombert wrote: post #42

Maybe someone with more understanding of kernel development could explain things to me. Does there have to be explicit kernel-level support to support a filesystem? Even if they remove support, does that stop anyone from releasing a kernel module and supporting it?

Not really, no. But you'd have to get the source and build the kernel module for the specific kernel it runs on. There are mechanisms to do this, such as DKMS (e.g. Virtualbox does this: it provides its kernel modules' code, OS/user provides kernel source, magic happens and sometimes it even works on the first try); having the module code always present in kernel source (even if it doesn't get built) is more convenient for building, but less convenient for kernel maintainers.

Re: Is it time to remove reiserfs?

#75

Post by draugadrotten »

frostwarrior wrote: post #24
kerneloftruth wrote: post #17

Earlier quoted context omitted.

Why erase history? It happened, and it's interesting.

Because companies may not want to be involved in a product called "PersonWhoIsConvictedWithMurder-FS". Let history be. But rename the project to something like ChameleonFS. Hans Reiser's mentions will still be in the git history.

Companies associated with all kinds of crimes exists everywhere. For recent war crimes, you can search yourself. For WW2, there is even a wikipedia list of companies involved with the Holocaust. One of them even own RedHat Linux now. https://en.wikipedia.org/wiki/List_of_companies_involved_in_...

Re: Is it time to remove reiserfs?

#76

Post by tombert »

Piskvorrr wrote: post #74
tombert wrote: post #42

Maybe someone with more understanding of kernel development could explain things to me. Does there have to be explicit kernel-level support to support a filesystem? Even if they remove support, does that stop anyone from releasing a kernel module and supporting it?

Not really, no. But you'd have to get the source and build the kernel module for the specific kernel it runs on. There are mechanisms to do this, such as DKMS (e.g. Virtualbox does this: it provides its kernel modules' code, OS/user provides kernel source, magic happens and sometimes it even works on the first try); having the module code always present in kernel source (even if it doesn't get built) is more convenie…

That's what I thought; I run zfs-dkms on my server, and I just assumed that other filesystems could do the same.

Re: Is it time to remove reiserfs?

#77

Post by rocqua »

captainmuon wrote: post #52

I wonder, how does the principle of not breaking userspace mesh with removing of file systems or drivers? I think some of the published cases where userspace would have been "broken" and Linus got angry were fairly minor, as in you might not even need to fix the software, the user just has to be aware of different defaults. Whereas updating a kernel to a version where the filesystem is not supported will definitely r…

I think, technically, file systems are not part of user-space. All of the code for file-systems lives in the Kernel.

In some technical sense, the filesystem is just an implementation detail of the kernel for things like 'read', 'write', and 'mmap'. Since this is an implementation detail, it can be considered 'not part of the public API of the kernel'.

Put differently, the promise not to break userspace is aimed at developers and not at actual users. The case of changing defaults is then a problem of developers because their programs are all of a sudden behaving differently.

Re: Is it time to remove reiserfs?

#78

Post by prmoustache »

more_corn wrote: post #35
daneel_w wrote: post #13

Earlier quoted context omitted.

Yes. Pretty much everyone is aware of the elephant in the room. It's just not relevant to address said elephant since it has no bearing on technical discussions, which is what the author of the e-mail thread pro-actively underlined.

Isn’t it relevant though? The sole author and support person is AFK for the foreseeable future.

Edward Shishkin has been the main maintener of reiser4 for years.

Re: Is it time to remove reiserfs?

#79

Post by cogman10 »

jordigh wrote: post #69

"WE DO NOT BREAK USERSPACE" https://lkml.org/lkml/2012/12/23/75 I was surprised to see that Linux has in fact removed other filesystems in the past (and I had to look up the word "senescent"). So the real news to me here is that a somewhat "major" break in userspace is being considered. Sure, ReiserFS might not be getting a lot of new installs, but the fact that people have submitted fixes to it within the past few y…

I mean, at the end of the day ReiserFS offers very little special compared to the other options already in the kernel. It never had a huge install base and has always been a major maintenance burden on the kernel.

AFAIK, BTRFS has everything Reiser has with a far better maintenance and ongoing feature expansion.

Really, the only reason to use reiser at this point is because you are dealing with data that you can't, for some reason, move to a new filesystem yet you still want to have updates to the kernel.

Re: Is it time to remove reiserfs?

#80

Post by chousuke »

jordigh wrote: post #69

"WE DO NOT BREAK USERSPACE" https://lkml.org/lkml/2012/12/23/75 I was surprised to see that Linux has in fact removed other filesystems in the past (and I had to look up the word "senescent"). So the real news to me here is that a somewhat "major" break in userspace is being considered. Sure, ReiserFS might not be getting a lot of new installs, but the fact that people have submitted fixes to it within the past few y…

Removing a kernel driver does not break userspace.

I mean, yes, your filesystem becomes inaccessible, but any programs that you could run if you could access that filesystem by some other means would still function. None of them depend on ReiserFS specifically for their function.

Userspace breakage is more about changing interfaces in such a way that applications using that interface change their behaviour somehow. This does not apply to removed drivers.

Post reply on HN