dCache
NFSv4.1 OPENATTR support
We need NFSv4.1 OPENATTR support. Could this be implemented for nfs4j, please?
Implementation for filesystems without ADS (Alternate Data Stream support) could be implemented with subdirs, e.g. a file "abc" would get a "abc@@nfsattrs" directory with sticky bit set. If "abc" gets deleted then the "abc@@nfsattrs" dir would be removed too.
Testing: pynfs has OPENATTR tests: https://git.linux-nfs.org/?p=cdmackay/pynfs.git;a=blob;f=nfs4.1/server41tests/st_xattr.py
pynfs tests extended attribute (supported by nfs4j). OPENATTR is something completely different and there are not plans to work on it ATM.
On Wed, 26 Mar 2025 at 11:19, Tiramisu Mokka @.***> wrote:
pynfs tests extended attribute (supported by nfs4j). OPENATTR is something completely different and there are not plans to work on it ATM.
— Reply to this email directly, view it on GitHub https://github.com/dCache/nfs4j/issues/143#issuecomment-2753893242, or unsubscribe https://github.com/notifications/unsubscribe-auth/BP7RUL7NUEEPNSOJDBJS3HL2WJWJVAVCNFSM6AAAAABVA32LW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJTHA4TGMRUGI . You are receiving this because you are subscribed to this thread.Message ID: @.***> [image: kofemann]kofemann left a comment (dCache/nfs4j#143) https://github.com/dCache/nfs4j/issues/143#issuecomment-2753893242
pynfs tests extended attribute (supported by nfs4j). OPENATTR is something completely different and there are not plans to work on it ATM.
— Reply to this email directly, view it on GitHub https://github.com/dCache/nfs4j/issues/143#issuecomment-2753893242, or unsubscribe https://github.com/notifications/unsubscribe-auth/BP7RUL7NUEEPNSOJDBJS3HL2WJWJVAVCNFSM6AAAAABVA32LW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJTHA4TGMRUGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Would you accept patches for OPENATTR support?
Lionel
Sure, if they don't break existing functionality :).
Please take a look at https://github.com/dCache/nfs4j?tab=readme-ov-file#how-to-contribute
How would the preferred API in the interface VirtualFileSystem look like for you? Just openAttr(FileName f) to get the inode to the virtual attr dir?
Yes, I have no idea yet what problem that will solve. For example, we are working currently on something that is called 'virtual directories'.
https://indico.cern.ch/event/1477299/contributions/6407503/attachments/3041040/5376579/dCache_hepix_2025.pdf
Is it in the same directon?
Yes, I have no idea yet what problem that will solve. For example, we are working currently on something that is called 'virtual directories'.
https://indico.cern.ch/event/1477299/contributions/6407503/attachments/3041040/5376579/dCache_hepix_2025.pdf
Is it in the same directon?
No, what we are primarily looking for is multiple data streams per file, for multiple different usage scenarios, including:
- cache streams, e.g. keep a compressed version of the data stream, similar how Windows implements per-file compression, or multiple scaled bitmap versions of a SVG file etc)
- attribute storage in XML (without size limit)
- MacOS data+resource fork implementation for the upcoming OS X NFSv4.2 driver
Got it. So, yeah, looks like openAttr(String name, boolean create) matches the nfs spec.