On 3/22/2023 3:47 PM, spacefrogg-open...@spacefrogg.net wrote:
OpenAFS does not maintain checksums. Checksums are neither transmitted in
the RXAFS_FetchData and RXAFS_StoreData RPCs messages nor are checksums
stored and compared when reading and writing to the vice partition.
Thanks for
> OpenAFS does not maintain checksums. Checksums are neither transmitted in
> the RXAFS_FetchData and RXAFS_StoreData RPCs messages nor are checksums
> stored and compared when reading and writing to the vice partition.
Thanks for clearing this up. So, volume inconsistencies are just detected on
On 3/22/2023 9:34 AM, Ciprian Craciun (ciprian.crac...@gmail.com) wrote:
On Wed, Mar 22, 2023 at 10:30 AM wrote:
OpenAFS implements its own CoW and using CoW below that again has no benefits and
disturbs the fileservers "free-space" assumptions. It knows when it makes
in-place updates and
Ciprian Craciun:
Well, I base this supposition on my simple observation with OpenAFS's
own client which is also out-of-tree and requires custom module builds
(via DKMS or equivalent).
For example I use OpenSUSE Tumbleweed (rolling release), and sometimes
I need to delay my updates until the
> At what level does OpenAFS implement CoW? Is it implemented at
> whole-file-level, i.e. changing a file that is part of a replicated /
> backup volume it will copy the entire file, or is it implemented at
> some range or smaller granularity level (i.e. it will change only that
> range, but
On Wed, Mar 22, 2023 at 10:30 AM wrote:
> OpenAFS implements its own CoW and using CoW below that again has no benefits
> and disturbs the fileservers "free-space" assumptions. It knows when it makes
> in-place updates and does not expect to run out of space in that situation.
At what level
On Wed, Mar 22, 2023 at 3:11 PM Dirk Heinrichs wrote:
> > it's not in-kernel; which means sooner or later one would encounter
> > problems.
>
> Can you please elaborate? I run two ZFS systems @home where one is an
> OpenAFS fileserver and client, the other one a client only. They both
> started
Ciprian Craciun:
it's not in-kernel; which means sooner or later one would encounter
problems.
Can you please elaborate? I run two ZFS systems @home where one is an
OpenAFS fileserver and client, the other one a client only. They both
started as Debian Stretch and have been updated to
> What is the reason behind disabling copy-on-write for BTRFS? Does it
> break OpenAFS in some way, or is it only the out-of-space issue?
OpenAFS implements its own CoW and using CoW below that again has no benefits
and disturbs the fileservers "free-space" assumptions. It knows when it makes
On Tue, Mar 21, 2023 at 9:32 PM wrote:
> The main ingredient on BTRFS is to disable Copy-on-Write for the respective.
> This also somewhat mitigates surprising out-of-space issues.
What is the reason behind disabling copy-on-write for BTRFS? Does it
break OpenAFS in some way, or is it only
Hi Ciprian,
I use ZFS and BTRFS for hosting volume partitions.
The main ingredient on BTRFS is to disable Copy-on-Write for the respective.
This also somewhat mitigates surprising out-of-space issues.
You need to provide the 'nodatacow' mount option.
Additionally, depending on your exact
Hello all!
I've searched the mailing archive (and the internet) about this topic,
but came a bit empty-handed, as the last proper mention of BTRFS on
this mailing list was 10 years ago.
So, given so much time has passed, I would like to ask the OpenAFS
community if anyone has any experience on
12 matches
Mail list logo
