Excited for Btrfs RAID1's "preferred read device" feature in Linux 6.14. This allows to have one fast device, example SSD backed bcache device and other slow cheap hard drive. We can set the bcache deice as preferred read device so reads are always fast.
It also wears down only one disk reducing the chance of both the disks evenly wearing out which increases the chances of both of them failing around the same time.

From the pull request:

> more read IO balancing strategies (experimental config), add two new
ways how to select a device for read if the profiles allow that (all RAID1*),
the current default selects the device by pid which is good on average
but less performant for single reader workloads
- select preferred device for all reads (namely for testing)
- round-robin, balance reads across devices relevant for the requested IO
range

Source: https://lore.kernel.org/lkml/cover.1737393999.git.dsterba@suse.com/

#btrfs #linux #linux_6_14 #filesystems #bcache #raid #raid1 #nas #selfhosting #selfhost

Making sure you're not a bot!

EXT2 | How does it work?

YouTube

Folks who know "rsync -F" because they already use it -- am I right in thinking that it adds these behaviours to a sync:

- recursively look for .rsync-filter files in every directory in the copy source, including the top-level

- apply the filters they each contain to the directory and subdirectories rooted at the same level that each file was found

- exclude those .rsync-filter files from being copied to the destination

Is that right? #rsync #sync #data #sysadmin #filesystem #filesystems

@cks

Which in turn then prompts the question of whether one with suitable chicanery could set it up as a correct i-node which fsck would consider allocated, but that would be unfixable.

Presumably the reference counting checks would detect it as an an orphan, but putting a directory entry referencing it in lost+found would not work.

Assuming that the reference counting pass does not also have a < ROOTINO short-circuit in the code too. (-:

#Unix #filesystems #FFS #UFS #FreeBSD

@cks

The same thought occurred to me. There have been cute tricks like that played. I've even played some of them on other systems.

But as far as I know that first entry in the i-node table was just unused.

I wonder whether fsck even checked it. Modern FreeBSD fsck_ffs does, but that's a very different beast.

#Unix #filesystems #FFS #UFS

@cks

Off By One Error in your post on this. (-:

Since 0 means a free directory entry, that's only 65535 i-nodes.

Mind you, at 8 i-nodes per block, you'd come close to the size of some contemporary discs with a maximally sized i-node table.

#Unix #filesystems

@spacehobo @brouhaha

Yes. Berkeley FFS broke things up into cylinder groups and had an allocation policy of putting various things in the same CG and other things not, because much the same idea was also useful for reducing seeks on discs.

(Even OS/2 got in on the act. (-: Its FAT filesytem driver put the extended attributes record for every file in front of the file data where it could. Which was why it was a bad idea to defragment the "EA DATA. SF" file so that it ended up stuffed all at the start of the volume.)

And the elevator algorithm in the block cache would at least make the tape do straight runs in one direction and then rewind, where it could.

Putting filesystem *and* swap on tape boggles the mind, though. (-:

#Unix #magtape #filesystems #tar #DEC #retrocomputing

Making openat(2) and friends more useful in practice https://www.undeadly.org/cgi?action=article;sid=20250529080623 #openbsd #openat #open #filesystems #security #development #unveil - now also with regression tests, more discussions on tech@
Making openat(2) and friends more useful in practice

@atoponce

There seem to be no answers matching "back". Both options match "up".

I think that you've overlooked an even more important poll that might be the shibboleth of our time: Does one go up and down a tree? Or does one go back and forth a tree?

Has the tree been chopped down?

(-:

#shell #POSIX #filesystems

PSA: If your software intended for #Linux cannot deal with filenames that contain
- spaces
- command line flags
- non-ASCII
- newlines
- control characters
- invalid UTF-8
then YOUR SOFTWARE IS WRONG AND BAD
and when it breaks IT IS YOUR FAULT and you DO NOT GET TO BLAME THE PEOPLE WHO NAMED THE FILES

#filesystems