On Fri, 13.06.14 16:41, Werner Fink (wer...@suse.de) wrote:

>                  fn = strappenda("/var/log/journal/", ids);
> -                (void) mkdir(fn, 0755);
> +                (void)mkdir(fn, 0755);
> +
> +                /*
> +                 * On journaling and/or compressing file systems avoid 
> doubling the
> +                 * efforts for the system, that is set NOCOW and NOCOMP 
> inode flags.
> +                 * Check for every single flag as otherwise some of the file 
> systems
> +                 * may return EOPNOTSUPP on one unkown flag (like BtrFS 
> does).
> +                 */
> +                if ((fd = open(fn, O_DIRECTORY)) >= 0) {
> +                        long flags;
> +                        if (ioctl(fd, FS_IOC_GETFLAGS, &flags) == 0) {
> +                                int old = flags;
> +                                if (!(flags&FS_NOATIME_FL) && ioctl(fd, 
> FS_IOC_SETFLAGS, flags|FS_NOATIME_FL) == 0)
> +                                        flags |= FS_NOATIME_FL;
> +                                if (!(flags&FS_NOCOW_FL) && ioctl(fd, 
> FS_IOC_SETFLAGS, flags|FS_NOCOW_FL) == 0)
> +                                        flags |= FS_NOCOW_FL;
> +                                if (!(flags&FS_NOCOMP_FL) && s->compress) {
> +                                        flags &= ~FS_COMPR_FL;
> +                                        flags |= FS_NOCOMP_FL;
> +                                }
> +                                if (old != flags)
> +                                        ioctl(fd, FS_IOC_SETFLAGS, flags);
> +                        }
> +                        close(fd);
> +                }

Humm, no. We won't tape over problems. If the defragging thing is a
performance issue we need to figure out why that happens, and as it
stands now it simply seems to be a weakness in the current btrfs kernel
code.

But we will not work around these problems from userspace just like
that. 

I mean, I am fine with giving btrfs special support and stuff, but I
want input from the right kernel guys about about this. If they
recommend this, then sure, we can do something like this, but we don't
blindly tape over this.

Sorry,

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to