[Errno 95] Operation not supported

[malakhanov-alexandr]

Getting this error during deduplication process (seems like no data corrupted though):

Traceback (most recent call last):
  File "/usr/local/bin/bedup", line 9, in <module>
    load_entry_point('bedup==0.10.0', 'console_scripts', 'bedup')()
  File "/home/sophos/.local/lib/python3.4/site-packages/bedup-0.10.0-py3.4-linux-x86_64.egg/bedup/__main__.py", line 497, in script_main
    sys.exit(main(sys.argv))
  File "/home/sophos/.local/lib/python3.4/site-packages/bedup-0.10.0-py3.4-linux-x86_64.egg/bedup/__main__.py", line 486, in main
    return args.action(args)
  File "/home/sophos/.local/lib/python3.4/site-packages/bedup-0.10.0-py3.4-linux-x86_64.egg/bedup/__main__.py", line 196, in vol_cmd
    dedup_tracked(sess, volset, tt, defrag=args.defrag)
  File "/home/sophos/.local/lib/python3.4/site-packages/bedup-0.10.0-py3.4-linux-x86_64.egg/bedup/tracking.py", line 405, in dedup_tracked
    dedup_tracked1(ds, comm1)
  File "/home/sophos/.local/lib/python3.4/site-packages/bedup-0.10.0-py3.4-linux-x86_64.egg/bedup/tracking.py", line 609, in dedup_tracked1
    dedup_fileset(ds, fileset, fd_names, fd_inodes, size)
  File "/home/sophos/.local/lib/python3.4/site-packages/bedup-0.10.0-py3.4-linux-x86_64.egg/bedup/tracking.py", line 632, in dedup_fileset
    deduped = clone_data(dest=dfd, src=sfd, check_first=True)
  File "/home/sophos/.local/lib/python3.4/site-packages/bedup-0.10.0-py3.4-linux-x86_64.egg/bedup/platform/btrfs.py", line 602, in clone_data
    ioctl_pybug(dest, lib.BTRFS_IOC_CLONE, src)
  File "/home/sophos/.local/lib/python3.4/site-packages/bedup-0.10.0-py3.4-linux-x86_64.egg/bedup/platform/btrfs.py", line 361, in ioctl_pybug
    return fcntl.ioctl(fd, ioc, arg)
OSError: [Errno 95] Operation not supported

I'm using kubuntu#15.04.

Command I'm trying to run is:

sudo bedup dedup --size-cutoff 0

Previously same command was running fine, started failing after I added some files.

[jamdox]

I'm also having this problem with dedup, without the cutoff option.

Running arch, tried it with a couple different kernels and with btrfs-progs-git, reinstalled bedup, reset data...

I'll try to dig up an older version of btrfs-progs in case this is a regression on their part.

[jamdox]

wow, the problem seems to be caused by having multiple btrfs devices mounted and not specifying which to scan.

[1a57danc3]

echo 3 > /proc/sys/net/ipv4/tcp_fastopen

[zerotohero]

I'm getting the same error just running

bedup dedup

It had actually been running fine for over a day, but then stopped in the middle and I can't get it to continue.

Ubuntu 18.04 with 4.18 kernel. BTRFS-progs version 4.17.1.

[lmburns]

I don't use this program. But has this issue ever been solved? I'm writing a Rust program that calls lsetxattr through a the C API and am getting Operation not supported (os error 95) messages when attempting to set extended attributes on a symlink.

The operation is not necessary; however, I am trying to set this as an option for the user and want to figure out how to solve it. I've seen other things online saying that my file system does not support symlinks, but that is incorrect. The file I am attempting to write extended attributes to is a symlink. File system is ext4. Here is the output of uname -

Linux archbox 5.17.6-arch1-1 #1 SMP PREEMPT Tue, 10 May 2022 23:00:39 +0000 x86_64 GNU/Linux

[zerotohero]

I didn't actually end up chasing this one down, but I did eventually find that there was a lot of non-correctable corruption with my filesystem and trying to read certain areas brought up all sorts of weird errors. May or may not have been related, but it's kind of in line with my case of bedup being able to run for some amount of time and then simply being unable to continue, possibly because it got to one of the corrupted files.
This also caused btrfs to write some errors out in dmesg. Again, maybe not related but maybe it'll help you track something down

[lmburns]

I'm not sure if my file system would be corrupted in any way. I wouldn't know how that would've happened. I see some things online, and in the xattr man page saying the following:

In user.* namespace, only regular files and directories can have
extended attributes. For sticky directories, only the owner and
privileged user can write attributes.

Here is a relevant stack overflow link. Though, what I don't understand is why functions like lsetxattr would exist if they weren't supposed to act on symlinks. Thank you for your reply.

Edit: However, this attr man page says this:

Attributes can be attached to all types of XFS inodes: regular files, directories, symbolic links, device nodes, etc.

[lmburns]

This will be the last comment I will make in here. For whatever it is worth, I think I found the solution:
If you're attempting to write extended attributes to a symlink, the trusted. namespace must be used, user. is not allowed to be written to symbolic links. Along with this, a superuser must perform this task.

If you read over the xattr and attr man pages, it explains it. Also here are two relevant stack overflow/exchange links:

• See: https://unix.stackexchange.com/questions/16537
• See: https://stackoverflow.com/questions/65985725