Live data from Hacker News

Is it time to remove reiserfs?

lkml.org

221–230 of 260 posts

Re: Is it time to remove reiserfs?

#221
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…

Read on: "If a change results in user programs breaking, it's a bug in the kernel." Linux regularly removes features. Entire architectures have been removed, including support for the 386. The alternative would be simply unworkable.

Re: Is it time to remove reiserfs?

#222

ReiserFS does have its benefits in highly specific use-cases. I have a filesystem with an absurd number of tiny files in it. I host a statically rendered wikipedia mirror. Tens of millions of gzipped html-files with a filesize in the range 1-5 Kb. ReiserFS is the only filesystem I know that deals even the slightest bit gracefully with this thanks to tail-packing.

> I host a statically rendered wikipedia mirror. Tens of millions of gzipped html-files with a filesize in the range 1-5 Kb.

Have you ever tried Kiwix (https://www.kiwix.org ) and looked at the ZIM format (https://en.wikipedia.org/wiki/ZIM_(file_format) ), in particular those for Wikipedia (https://download.kiwix.org/zim ) ?

Re: Is it time to remove reiserfs?

#223

Earlier quoted context omitted.

> If their machines fail, they don’t care This myth is being perpetuated despite btrfs devs (who work at facebook) stating the exact opposite many times over. Every FS corruption and weird behavior is put aside and investigated. They very much do care. https://lwn.net/ml/fedora-devel/03fbbb9a-7e74-fc49-c663-3272... Please read the whole thread before repeating this nonsense, or at least every email sent there by Jose…

As a tl,dr: “Also keep in mind we pay really close attention to burn rates for our drives, because obviously at our scale it translates to millions of dollars. Btrfs has improved our burn rates with the compression, as the write amplification goes drastically down, thus extending the life of the drives.” As with anything it comes down to money. Yes a machine going down doesn’t impact the cluster but it does impact th…

Just pointing out that "caring about physical drive failure" and "caring about disk corruption or data loss" are completely independent and the latter does not directly equate big money (as there are already systems and SOP in place to deal with handling failed servers). Btrfs isn't notorious for actually frying disks, just the data on them.

Re: Is it time to remove reiserfs?

#224

Earlier quoted context omitted.

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. T…

If your application interfaces with ReiserFS directly (fsck/servicing scripts), or you expect to see certain performance patterns (like high speed on lots of smaller files), then I would consider this userspace breakage.

In the same sense, Linux broke userspace for 386 users in 3.8 because the users expected Linux to run on their computer. An optional build-time feature being removed does not break userspace.

Re: Is it time to remove reiserfs?

#225

Earlier quoted context omitted.

A filesystem in the kernel isn't userspace.

Isn't "mount -t reiserfs" userspace though? Presumably removing reiserfs from the kernel would also break that use of the 'mount' syscall.

The syscall would return ENODEV, just like any other case where a user attempts to mount a filesystem type that isn't compiled for the running kernel.

Re: Is it time to remove reiserfs?

#226
post #77

Earlier quoted context omitted.

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 de…

I disagree that filesystem support is not part of userspace. In userspace, I run "mount -t reiserfs ....", and it mounts a filesystem. If the kernel deletes the reiserfs code, the userspace mount command / kernel 'mount' syscall will fail. That seems like a very clear userspace thing that breaks. Is there a reason that the mount syscall no longer accepting a previously valid argument isn't a userspace breaking change…

`mount -t reiserfs` will also fail if ReiserFS isn't built for the running kernel. mount(2) fails with ENODEV and prints an accurate message: "unknown filesystem type 'reiserfs'". This isn't breaking userspace. The syscall and program do the correct thing based on the capabilities of the current kernel.

In any case, the ship has long since sailed on removing filesystems from the kernel. The original extfs is no longer available, nor is xiafs, nor are some virtual filesystems like devfs, etc. "A command that used to do something no longer does because the feature is no longer in the kernel" is commonplace in Linux history and is not considered "breaking userspace".

Re: Is it time to remove reiserfs?

#227
post #94

Earlier quoted context omitted.

don't murder your wife, got it. this is the kind of high level advice i come here for

Alternatively, if you do it’s in the best interest of your open source software that you don’t get caught.

hide the body, got it

Re: Is it time to remove reiserfs?

#228

> NB: Please don't discuss the personalities involved. Ah, but that's all I can think about when I read about reiserfs. For anyone who is unaware, the author, Hans Reiser, killed his wife and hid her body. There was a long and public investigation and he was found guilty. He later produced her body as part of a plea deal.

It's unfortunate that ReiserFS is named after Hans Reiser; other people were working on it too (well before the murder, see e.g. [1] for a crude overview), and there's nothing stopping anyone from maintaining and developing it, no matter what Hans Reiser did. Yet in large part due to the name, it's strongly linked to him :-/ If Theodore Ts'o would have been convicted of murder the ext* filesystems probably would have…

I feel like there's a small tautology here- who is most likely to name the software package after themselves? A narcissist, of course, and narcissism is a component of sociopathy.

Re: Is it time to remove reiserfs?

#229

Earlier quoted context omitted.

Years ago this was very similar to our use case, only much smaller file sizes, and Reiser saved an amazing amount of overhead. The systems were hosting map tiles of the entire Earth, and a lot of them were solid blue (ocean) or solid beige (unoccupied land). Those files were something like 60-300 bytes, going from memory. Reiser was basically the only FS that would handle that reasonably.

Oh I have a repository of tens of millions of small json files, and xfs chokes on that specific partition it's amazing. 5 minutes for a ls in the root folder (with only 2 folders). Tried moving it disk to disk in case I was on a broken disk, but no.

Unless there is a good reason, I think in that situation I would probably try to avoid storing those tens of millions of small json files directly on the filesystem. For example : have you considered storing that data in jsonb/postgresql https://www.compose.com/articles/faster-operations-with-the-... ? (or even just in an sqlite db https://www.sqlite.org/fasterthanfs.html )

Re: Is it time to remove reiserfs?

#230

ReiserFS is a lesson in project naming. When I started in Linux full-time, back in the early 2000s, I was presented with different fs options - the installer did not give me any information on benefits, or on which ones were considered "stable". ext2 was available, but it also had a built-in version number, and I feared that once ext3 eventually rolled over, it might be incompatible. So I chose the fs that came with…

I think you made this point: The only way for this filesystem to survive, is to rename it. It's the only way it will continue to have users.

If you chose what filesystem you use based on the name you have a big problem.
Post reply on HN