Re: unsolvable technical issues?
Jukka Larja wrote: waxhead wrote 24.6.2018 klo 1.01: Nikolay Borisov wrote: On 22.06.2018 02:13, waxhead wrote: According to this: https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , section 1.2 It claims that BTRFS still have significant technical issues that may never be resolved. Could someone shed some light on exactly what these technical issues might be?! What are BTRFS biggest technical problems? That's a question that needs to be directed at the author of the statement. I think not, and here's why: I am asking the BTRFS developers a general question , with some basis as to why I became curious. The question is simply what (if any) are the biggest technical issues in BTRFS because one must expect that if anyone is going to give me a credible answer it must be the people that hack on BTRFS and understand what they are working on and not the stratis guys. It would surprise me if they knew better than the BTRFS devs. I think the problem with that question is that it is too general. Duncan's post already highlights several things that could be a significant problem for some user while being non-issue for most. Without more specific problem description, best you can hope for is speculation on things that Btrfs currently does badly. -Jukka Larja Well, I still don't agree (apparently I am starting to become difficult). There is a "roadmap" on the BTRFS wiki that describes features implemented and feature planned for example. Naturally people are working on improvements to existing features and prep-work for new features. If some of this work is not moving ahead due to design issues it sounds likely that someone would know about it by now. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unsolvable technical issues?
waxhead wrote: > Jukka Larja wrote: >> waxhead wrote 24.6.2018 klo 1.01: >>> Nikolay Borisov wrote: On 22.06.2018 02:13, waxhead wrote: > According to this: > > https://stratis-storage.github.io/StratisSoftwareDesign.pdf > Page 4 , section 1.2 > > It claims that BTRFS still have significant technical issues that may > never be resolved. > Could someone shed some light on exactly what these technical issues > might be?! What are BTRFS biggest technical problems? That's a question that needs to be directed at the author of the statement. >>> I think not, and here's why: I am asking the BTRFS developers a >>> general question , with some basis as to why I became curious. The >>> question is simply what (if any) are the biggest technical issues in >>> BTRFS because one must expect that if anyone is going to give me a >>> credible answer it must be the people that hack on BTRFS and >>> understand what they are working on and not the stratis guys. It would >>> surprise me if they knew better than the BTRFS devs. >> >> I think the problem with that question is that it is too general. >> Duncan's post already highlights several things that could be a >> significant problem for some user while being non-issue for most. >> Without more specific problem description, best you can hope for is >> speculation on things that Btrfs currently does badly. >> >> -Jukka Larja > > Well, I still don't agree (apparently I am starting to become > difficult). There is a "roadmap" on the BTRFS wiki that describes > features implemented and feature planned for example. Naturally people > are working on improvements to existing features and prep-work for new > features. If some of this work is not moving ahead due to design issues > it sounds likely that someone would know about it by now. This one doesn't seem to be moving ahead, while it seems like a very promising one: Hot data tracking and moving to faster devices (or provided on the generic VFS layer) It would be really fantastic to just add a ssd to a pool of hdd's and have fsync sensitive stuff run normally (dpkg on raid10 with 50 snapshots currently can take hours to do a few minute job) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unsolvable technical issues?
On 06/23/2018 07:11 AM, Duncan wrote: > waxhead posted on Fri, 22 Jun 2018 01:13:31 +0200 as excerpted: > >> According to this: >> >> https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , >> section 1.2 >> >> It claims that BTRFS still have significant technical issues that may >> never be resolved. >> Could someone shed some light on exactly what these technical issues >> might be?! What are BTRFS biggest technical problems? >> >> If you forget about the "RAID"5/6 like features then the only annoyances >> that I have with BTRFS so far is... >> >> 1. Lack of per subvolume "RAID" levels >> 2. Lack of not using the deviceid to re-discover and re-add dropped >> devices >> >> And that's about it really... > > ... And those both have solutions on the roadmap, with RFC patches > already posted for #2 (tho I'm not sure they use devid) altho > realistically they're likely to take years to appear and be tested to > stability. Meanwhile... > > While as the others have said you really need to go to the author to get > what was referred to, and I agree, I can speculate a bit. While this > *is* speculation, admittedly somewhat uninformed as I don't claim to be a > dev, and I'd actually be interested in what others think so don't be > afraid to tell me I haven't a clue, as long as you say why... based on > several years reading the list now... > > 1) When I see btrfs "technical issue that may never be resolved", the #1 > first thing I think of, that AFAIK there are _definitely_ no plans to > resolve, because it's very deeply woven into the btrfs core by now, is... > > Filesystem UUID Identification. Btrfs takes the UU bit of Universally > Unique quite literally, assuming they really *are* unique, at least on > that system, and uses them to identify the possibly multiple devices that > may be components of the filesystem, a problem most filesystems don't > have to deal with since they're single-device-only. Because btrfs uses > this supposedly unique ID to ID devices that belong to the filesystem, it > can get *very* mixed up, with results possibly including dataloss, if it > sees devices that don't actually belong to a filesystem with the same UUID > as a mounted filesystem. As partial workaround you can disable udev btrfs rules and then do a "btrfs dev scan" manually only for the device which you need. The you can mount the filesystem. Unfortunately you cannot mount two filesystem with the same UUID. However I have to point out that also LVM/dm might have problems if you clone a PV [...] der say 3-5 (or 5-7, or whatever) > years. These could arguably include: > > 2) Subvolume and (more technically) reflink-aware defrag. > > It was there for a couple kernel versions some time ago, but "impossibly" > slow, so it was disabled until such time as btrfs could be made to scale > rather better in this regard. Did you try something like that with XFS+DM snapshot ? No you can't, because defrag in XFS cannot traverse snapshot (and I have to suppose that defrag cannot be effective on a dm-snapshot at all).. What I am trying to point out is that even tough btrfs is not the fastest filesystem (and for some workload is VERY slow), when you compare it when few snapshots were presents LVM/dm is a lot slower. IMHO most of the complaint which affect BTRFS, are due to the fact that with BTRFS an user can quite easily exploit a lot of features and their combinations. When a the slowness issue appears when some advance features combinations are used (i.e. multiple disks profile and (a lot of ) snapshots), this is reported as a BTRFS failure. But in fact even LVM/dm is very slow when the snapshot is used. > > There's no hint yet as to when that might actually be, if it will _ever_ > be, so this can arguably be validly added to the "may never be resolved" > list. > > 3) N-way-mirroring. > [...] This is not an issue, but a not implemented feature > > 4) (Until relatively recently, and still in terms of scaling) Quotas. > > Until relatively recently, quotas could arguably be added to the list. > They were rewritten multiple times, and until recently, appeared to be > effectively eternally broken. Even tough what you are reporting is correct, I have to point out that the quota in BTRFS is more complex than the equivalent one of the other FS. In fact it handles (good or bad) quota of gorup of subvolumes. How this concept could be translated in terms of "stratis" [...] > > As for stratis, supposedly they're deliberately taking existing proven in > multi-layer-form technology and simply exposing it in unified form. They > claim this dramatically lessens the required new code and shortens time- > to-stability to something reasonable, in contrast to the about a decade > btrfs has taken already, without yet reaching a full feature set and full > stability. IMO they may well have a point, tho AFAIK they're still new > and immature themselves and (I believe)
Re: [PATCH v2] btrfs: return EUCLEAN if extent_inline_ref type is invalid
On 06/22/2018 05:40 PM, David Sterba wrote: On Fri, Jun 22, 2018 at 04:18:01PM +0800, Su Yue wrote: If type of extent_inline_ref found is not expected, filesystem may have been corrupted, should return EUCLEAN instead of EINVAL. No functional changes. Signed-off-by: Su Yue --- Changelog: v2: Add changes in build_backref_tree, get_extent_inline_ref and add_inline_refs. v2 looks good. I saw one implicit check for invalid ref in add_data_references that still returns -EINVAL. The implicit check is located in relocation.c:3804. I changed it in v1 which is not listed in changedlog. Did I need to sent v3 to list all functions in commit message? Thanks, Su -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] btrfs: return EUCLEAN if extent_inline_ref type is invalid
On 06/25/2018 09:28 AM, Su Yue wrote: On 06/22/2018 05:40 PM, David Sterba wrote: On Fri, Jun 22, 2018 at 04:18:01PM +0800, Su Yue wrote: If type of extent_inline_ref found is not expected, filesystem may have been corrupted, should return EUCLEAN instead of EINVAL. No functional changes. Signed-off-by: Su Yue --- Changelog: v2: Add changes in build_backref_tree, get_extent_inline_ref and add_inline_refs. v2 looks good. I saw one implicit check for invalid ref in add_data_references that still returns -EINVAL. The implicit check is located in relocation.c:3804. I changeds/3804/3801 it in v1 which is not listed in changedlog. Did I need to sent v3 to list all functions in commit message? Thanks, Su -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] btrfs: Use iocb to derive pos instead of passing a separate parameter
So, this is the updated version of https://patchwork.kernel.org/patch/10063039/
This time xfstest is ok and
Reviewed-by: Misono Tomohiro
On 2018/06/18 2:39, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> struct kiocb carries the ki_pos, so there is no need to pass it as
> a separate function parameter.
>
> generic_file_direct_write() increments ki_pos, so we now assign pos
> after the function.
>
> Signed-off-by: Goldwyn Rodrigues
> ---
> fs/btrfs/file.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
> index f660ba1e5e58..f84100a60cec 100644
> --- a/fs/btrfs/file.c
> +++ b/fs/btrfs/file.c
> @@ -1569,10 +1569,11 @@ static noinline int check_can_nocow(struct
> btrfs_inode *inode, loff_t pos,
> return ret;
> }
>
> -static noinline ssize_t __btrfs_buffered_write(struct file *file,
> -struct iov_iter *i,
> -loff_t pos)
> +static noinline ssize_t __btrfs_buffered_write(struct kiocb *iocb,
> +struct iov_iter *i)
> {
> + struct file *file = iocb->ki_filp;
> + loff_t pos = iocb->ki_pos;
> struct inode *inode = file_inode(file);
> struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
> struct btrfs_root *root = BTRFS_I(inode)->root;
> @@ -1804,7 +1805,7 @@ static ssize_t __btrfs_direct_write(struct kiocb *iocb,
> struct iov_iter *from)
> {
> struct file *file = iocb->ki_filp;
> struct inode *inode = file_inode(file);
> - loff_t pos = iocb->ki_pos;
> + loff_t pos;
> ssize_t written;
> ssize_t written_buffered;
> loff_t endbyte;
> @@ -1815,8 +1816,8 @@ static ssize_t __btrfs_direct_write(struct kiocb *iocb,
> struct iov_iter *from)
> if (written < 0 || !iov_iter_count(from))
> return written;
>
> - pos += written;
> - written_buffered = __btrfs_buffered_write(file, from, pos);
> + pos = iocb->ki_pos;
> + written_buffered = __btrfs_buffered_write(iocb, from);
> if (written_buffered < 0) {
> err = written_buffered;
> goto out;
> @@ -1953,7 +1954,7 @@ static ssize_t btrfs_file_write_iter(struct kiocb *iocb,
> if (iocb->ki_flags & IOCB_DIRECT) {
> num_written = __btrfs_direct_write(iocb, from);
> } else {
> - num_written = __btrfs_buffered_write(file, from, pos);
> + num_written = __btrfs_buffered_write(iocb, from);
> if (num_written > 0)
> iocb->ki_pos = pos + num_written;
> if (clean_page)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
