similar to: btrfs and quotas: best practice?

On Wed, 10 Jul 2024 19:19:44 +0200 "Stefan G. Weichinger via samba" <samba at lists.samba.org> wrote: > > today I migrated a customer to a new samba-domain-member/file-server > > The main shares are based on btrfs-subvolumes. > > The admin there wants to limit the visible space to discipline the > users ... > > I created a quota group in btrfs and

Am 11.07.24 um 12:47 schrieb Rowland Penny via samba: > Hi Stefan, I do not use use btrfs, so I cannot fully answer your > question, but a quick internet search using 'samba btrfs quota' turned > up this Samba bug: > > https://bugzilla.samba.org/show_bug.cgi?id=10541 > > Perhaps that will help. thank you. Hmm. I learned about vfs_btrfs now and set up a test share

HFvs> Hello, >>> In my impression: Yes. Also, this problem seems to affect also zfs HFvs> and >> I'm mostly interested in the claim that ZFS is affected. >> I haven't followed this thread carefully, but what exactly is the problem we're >> talking about, and how do we know it impacts ZFS? >> [Something more than a single one-liner in that

On 18/05/2019 14:19, Hendrik Friedel wrote: > Hello > >> No, probably a lack of users using your combination of Samba, btrfs >> and quotas. > I would have thought that btrfs is becoming more mainstream now. And > then, Samba and Quotas should be rather common... >> Is btrfs becoming more common ? > >> Of course, more info may help, what is in your smb.conf

On Mon, May 20, 2019 at 05:54:13PM +0000, Hendrik Friedel via samba wrote: > Hello, > > > Is btrfs becoming more common ? > In my impression: Yes. Also, this problem seems to affect also zfs and thus > all (?) file systems that support checksums and scrubbing in linux; > consequently all filesystems that are the choice of users who need this for > ensuring data

On Friday 21 November 2014 13:17:55 Hu Tao wrote: > btrfs_subvolume_create creates only subvolumes. btrfs_subvolume_delete > deletes subvolumes or snapshots. > > Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> > --- > generator/actions.ml | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/generator/actions.ml b/generator/actions.ml

This testscript creates reflinks to files on different subvolumes, overwrites the original files and reflinks, and moves reflinked files between subvolumes. Originally submitted as testcase 302, changes are made based on comments from Eric: http://oss.sgi.com/archives/xfs/2013-03/msg00231.html Two new common/rc functions used in this script (_require_cp_reflink and _verify_reflink) have been

We have a problem with btrfs subvolumes, as they can hold a filesystem which can be mounted, but aren't describable using only the name of a block device. Specifically they need at least a block device and a subvolume name. There are several APIs which operate on filesystems which currently describe it using only a block device. I've listed them all below. In all cases, these APIs need

Mark Haney wrote: > On 09/07/2017 01:57 PM, hw wrote: >> >> Hi, >> >> is there anything that speaks against putting a cyrus mail spool onto a >> btrfs subvolume? >> > I might be the lone voice on this, but I refuse to use btrfs for anything, much less a mail spool. I used it in production on DB and Web servers and fought corruption issues and scrubs

When listing the subvolumes of a btrfs filesystem, ignore the default subvolume: we get the content of it when mounting the whole device (without specifying any particular subvolume), so avoid listing it twice. --- src/listfs.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/listfs.c b/src/listfs.c index 98e74c7..de3b6f5 100644 --- a/src/listfs.c +++ b/src/listfs.c @@ -169,8

On 20/05/2019 19:47, Hendrik Friedel wrote: > Hello, > >>>> You posted this: >>>> I am using Openmediavault (debian based NAS distribution), which is >>>> not actively supporting btrfs >>>> It is this that I was referring to. >>> Ah, yes. >>> OMV intended to move to btrfs as the only choice with the next >>>

We've currently got a bug in libguestfs which means we can't inspect filesystems in btrfs subvolumes: https://bugzilla.redhat.com/show_bug.cgi?id=824021 This is the default configuration if you select btrfs in F17+. The issue is that it requires an api to fix it, as the return values of inspect_os, inspect_get_filesystems and inspect_get_mountpoints can't express a btrfs

Hello all, in IRC we had a discussion on how we could solve sending live subvolumes and how to send subvolumes without the need to administrate/keep old snapshots for incremental sends. One of the ideas was to introduce "sendshots", which are basically snapshots where no refs are counted for file data. This means, that when file data is changed in the sendshot origin, we do not consume

Hi All, the following patches implement the recursively snapshotting and deleting of a subvolume. To snapshot recursively you must pass the -R switch: # btrfs subvolume create sub1 Create subvolume ''./sub1'' # btrfs subvolume create sub1/sub2 Create subvolume ''sub1/sub2'' # btrfs subvolume snapshot -R sub1 sub1-snap Create a snapshot of

On Friday 17 October 2014 11:25:03 Olaf Hering wrote: > On Thu, Oct 16, Olaf Hering wrote: > > I can probably add a check somewhere to catch the whatever=="@". A > > better fix would be to check if a given subvolume is for the entire > > partition. > > So after talking to David Sterba there is no way to tell if a given > subvolume is for the entire

virt-filesystem -l tries to get the size of btrfs subvolumes, which results in an error. Teach it to skip the subvolumes. --- cat/filesystems.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/cat/filesystems.c b/cat/filesystems.c index f1c2852..f679517 100644 --- a/cat/filesystems.c +++ b/cat/filesystems.c @@ -476,9 +476,27 @@ do_output_filesystems

virt-filesystem -l tries to get the size of btrfs subvolumes, which results in an error. Teach it to skip the subvolumes. --- cat/filesystems.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/cat/filesystems.c b/cat/filesystems.c index f1c2852..cfdac86 100644 --- a/cat/filesystems.c +++ b/cat/filesystems.c @@ -476,9 +476,28 @@ do_output_filesystems

I've just noticed that I'm having issues with finding files using "locate" when those files are on btrfs subvolume mounts. The issue is that updatedb cannot discern the difference between a btrfs bind mount and btrfs subvolume [1]. This generally means that if you're using btrfs subvolume mounts and updatedb at the same time, and you want to index those subvolumes,

We create two subvolumes (meego_root and meego_home) in btrfs root directory. And set meego_root as default mount subvolume. After we remount btrfs, meego_root is mounted to top directory by default. Then when we try to mount meego_home (subvol=meego_home) to a subdirectory, it failed. The problem is when default mount subvolume is set to meego_root, we search meego_home in meego_root but can not

Hey there! Here are a few patches to fix unrelated things: one fixes the configure for older ncurses releases having no pkg-config files. The other two are fixing what Richard mentioned about guestfs subvolumes display Cédric Bosdonnat (3): configure: handle older version of ncurses api: add mountable_device and mountable_subvolume fish: fix btrfs subvolumes display in error case