Talk:ZFS

Data recovery
"This led to threads in online forums where ZFS developers sometimes tried to provide ad-hoc help to home and other small scale users, facing loss of data due to their inadequate design or poor system management." Link is not to a thread in a "online forum" but to a blog post about data recovery by preeminent ZFS developers. — Preceding unsigned comment added by 68.12.71.26 (talk) 08:09, 21 November 2023 (UTC)

Other limitations specific to ZFS
"Other limitations specific to ZFS" mostly aren't specific to ZFS. "Capacity expansion is normally achieved by adding groups of disks as a top-level vdev: simple device, RAID-Z, RAID Z2, RAID Z3, or mirrored..." is not a limitation. It mostly describe how RAID topology works. "IOPS performance of a ZFS storage pool can suffer if the ZFS raid is not appropriately configured." As is the case with all RAIDs. "Resilver (repair) of a failed disk in a ZFS RAID can take a long time which is not unique to ZFS, it applies to all types of RAID, in one way or another." Statement even admits this is not particular to ZFS! — Preceding unsigned comment added by 68.12.71.26 (talk) 08:01, 21 November 2023 (UTC)


 * I concur. Much of this just seems like padding to try to give the impression that there are greater limitations than actually exist. cheers. anastrophe, an editor he is. 08:29, 21 November 2023 (UTC)

fragmentation problem
((Note: This discussion arose on my talk page after I'd reverted the changes editor Robercik st had added. I think it's at a point where more 'eyeballs' are needed to come to consensus, so I'm copying it here unaltered for further discussion.))

You can read about this in https://github.com/openzfs/zfs/issues/3582 if you need more info Robercik st (talk) 03:06, 13 December 2023 (UTC)


 * The problem is there's multiple issues at work here. First, the question of whether or not free space fragmentation is the cause of performance issues, or rather over-utilization of the disk space. Virtually all filesystems are prone to performance issues as available free space diminishes, and since we don't have meaningful metrics to rely on, we can't ascribe one over the other.
 * Secondly, most of what you've written is narrative opinion. The link to the ZFS code discussions isn't a reliable source for the claims being made - not by wikipedia's standards. You'd need to find a secondary source that describes these issues.
 * Lastly - I suspect you may not be a native english speaker, based on the many grammatical and spelling errors in the content presented. That's not a problem itself, fluency in any language isn't easy. However, for the content to be appropriate to the english wikipedia, it would have to have all the errors fixed before being posted into the public encyclopedia. That however is dependent upon the precedent issues with the content that I described. Numerous opinions on the 'net suggest that by far the larger issue is over-utilization; fragmentation being pointed to as the proximate cause of performance issues hasn't been determined as fact.
 * If you can find a better source - a general technology news site would be a good start - then possibly the claims could be notable for the article. I looked around and couldn't find any discussion of the matter - only blog posts and forum commentary, which just aren't acceptable for making broad claims in the article. cheers. anastrophe, an editor he is. 06:27, 13 December 2023 (UTC)
 * So i this docs article from oracle you have:
 * https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/manage-zfs/storage-pool-practices-performance.html#GUID-3568A4BD-BE69-4F17-8A2E-A7ED5C7EFA79
 * If a large percentage (more than 50%) of the pool is made up of 8k chunks (DBfiles, iSCSI Luns, or many small files) and have constant rewrites, then the 90% rule should be followed strictly.
 * If all of the data is small blocks that have constant rewrites, then you should monitor your pool closely once the capacity gets over 80%. The sign to watch for is increased disk IOPS to achieve the same level of client IOPS.
 * So there is really confirming what i wrote whether is is space or fragmentation or both but I think that users should know that things because they place on zfs big TB of data so moving it will be very costly especially on production. And there is scarse info about that real problem in zfs.
 * I don't know of such requirements on ext4 for example and from my experience postgres workloads works very well after 90 % full FS on ext4 so that kind of problems shouldbe stated surely
 * Of course you can correct gramar errors but idea stays right :) Robercik st (talk) 15:17, 13 December 2023 (UTC)
 * That's an interesting and useful link. However - it's important to be aware of the WP rules about synthesis. The Oracle page is a 'good/best practices' guidance page: it doesn't state anywhere that these are, specifically, limitations, deficiencies, or shortcomings of ZFS - they're merely suggestions for maintaining good performance. So, the material would certainly be useful in the article, but it can't be presented specifically as a "limitation" unique to ZFS.
 * If you want to craft a new segment, perhaps to go under the 'read/write efficiency' section? - I recommend posting it to the ZFS talk page, where I'll be happy to do 'wordsmithing' on it so it reads better for article space. cheers. anastrophe, an editor he is. 21:20, 13 December 2023 (UTC)
 * But I didn't find such recomendation for eg.: ext4, xfs or other filesystems so I find it very specific limitation of zfs which can surprise users in very bad way in case of TB of data. An also it confirms what it is stated in https://github.com/openzfs/zfs/issues/3582 especially comment with paragraph from author of ZFS: Matt Ahrenz on ZFS / "Block-pointer Rewrite project for ZFS Fragmentation". So there is clearly problem specific for zfs. Robercik st (talk) 16:40, 14 December 2023 (UTC)
 * But again, you've just given the definition of why WP:SYNTHESIS isn't accepted: "Do not combine material from multiple sources to reach or imply a conclusion not explicitly stated by any source. Similarly, do not combine different parts of one source to reach or imply a conclusion not explicitly stated by the source."
 * We can't make the conclusion that it's a unique limitation of ZFS; a reliable source has to. Nowhere in the quote from Matt Ahrenz does he mention ext4, XFS, ReiserFS, Fat32, or any other filesystem, nor does the Oracle document.
 * If you can find a reliable source that says that it is a limitation unique to ZFS, then by all means, that would be appropriate to the article. Until then, we can't make claims that can't be verified directly from the sources. cheers. anastrophe, an editor he is. 18:29, 14 December 2023 (UTC)
 * Ok but can we put fragmentation as limitation specific to zfs in that it is not fixed so we can;t defragment as Matt Ahrenz says so ? Robercik st (talk) 01:54, 15 December 2023 (UTC)
 * Hey Robert, before we go further, I'd like your permission to copy this whole thread over to the ZFS talk page. I don't want there to be any sense that I'm "gatekeeping" the content - I'm not an expert, though I did run ZFS filesystems in production for many years. The fragmentation issue - from what I've read - is quite a complicated matter, since it's not fragmentation in the sense the majority of people think of it - as in, it's not file fragmentation, it's free-space fragmentation.
 * But - with your permission, let's move this over there so that we can get more eyeballs on the matter and come to a collaborative consensus. Sound okay? cheers. anastrophe, an editor he is. 02:59, 15 December 2023 (UTC)
 * Ofcourse You can copy
 * Ofcourse it is free-space fragmentation issue and i believe that Oracle recommendations are because of that problem with fragmentation and this is clearly problem with zfs itself. I can hide itself when we have mostly cold storage but it hit hard in cases described in Oracle docs so we need to expose that in article for sure it creator of zfs says we have problem ;). Also very suspicious is that Oracle doesn't give solution to revert this lower performance and if it is because of fragmentation there is no solution other than rewriting whole dataset :( which is shame. Robercik st (talk) 16:46, 15 December 2023 (UTC)
 * Shame for fs that is advertised as last word in FS :) Robercik st (talk) 16:48, 15 December 2023 (UTC)

((This is the end of the discussion that was on my talk page)) cheers. anastrophe, an editor he is. 18:48, 15 December 2023 (UTC)