similar to: [PATCH] xfs: add new api xfs-growfs

more daemon codes covered Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com> --- daemon/debug.c | 2 +- daemon/devsparts.c | 2 +- daemon/guestfsd.c | 6 +++--- daemon/labels.c | 4 ++-- daemon/ldm.c | 16 ++++++++-------- daemon/md.c | 10 +++++----- daemon/mkfs.c | 2 +- daemon/parted.c | 8 ++++---- daemon/statvfs.c | 8 ++++---- daemon/sync.c

Hi, We have recently switched from XFS to ext3 do to various corruption scenarios that were witnessed. Does ext3 have something like xfs_growfs for growing the FS to the end of the underlying partition? Thanks, Menny

This simple patch adds support for the BSD "growfs" command, so you can grow BSD filesystems [in theory -- see below]. It also adds a new optional group called "ufsutils" which indicates if the libguestfs API supports the guestfs_ufs_growfs call, since it's not available on Fedora. (http://libguestfs.org/guestfs.3.html#availability) I tested this on Debian, and although

Previously we had lots of types like String, Device, StringList, DeviceList, etc. where Device was just a String with magical properties (but only inside the daemon), and DeviceList was just a list of Device strings. Replace these with some simple top-level types: String StringList and move the magic into a subtype. The change is mechanical, for example: old

On Tue, 2017-09-19 at 17:02 +0200, L.P.H. van Belle via samba wrote: > Hai Mark, > > I see the bugreport for this is still untouched. > https://bugzilla.samba.org/show_bug.cgi?id=11998 I've closed that bug now. Extensive work has been done to add this feature to Samba 4.7, due out this week: https://wiki.samba.org/index.php/Setting_up_Audit_Logging Two new debug classes,

Very large but mechanical change to the generator. Rich.

This is a follow-up to the other generator changes in: https://www.redhat.com/archives/libguestfs/2017-February/msg00217.html Rich.

Add xfs_info to show the geometry of the xfs filesystem. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- Hi Rich, I got an odd error, can you help me with this error or give me a debug method? Thanks, Wanlong Gao daemon/Makefile.am | 1 + daemon/xfs.c | 278 +++++++++++++++++++++++++++++++ generator/generator_actions.ml

Hi Liam, I saw that your XFS uses ?imaxpct=25? which for an arbiter brick is a little bit low. If you have free space on the bricks, increase the maxpct to a bigger value, like:xfs_growfs -m 80 /path/to/brickThat will set 80% of the Filesystem for inodes, which you can verify with df -i /brick/path (compare before and after).?This way?you won?t run out of inodes in the future. Of course, always

Hi Strahil, We're using gluster to act as a share for an application to temporarily process and store files, before they're then archived off over night. The issue we're seeing isn't with the inodes running out of space, but the actual disk space on the arb server running low. This is the df -h? output for the bricks on the arb server: /dev/sdd1 15G 12G 3.3G 79%

Thanks for the clarification. That behaviour is quite weird as arbiter bricks should hold?only metadata. What does the following show on host?uk3-prod-gfs-arb-01: du -h -x -d 1?/data/glusterfs/gv1/brick1/brickdu -h -x -d 1?/data/glusterfs/gv1/brick3/brickdu -h -x -d 1 /data/glusterfs/gv1/brick2/brick If indeed the shards are taking space -?that is a really strange situation.From which version

Hi Strahil, This is the output from the commands: root at uk3-prod-gfs-arb-01:~# du -h -x -d 1 /data/glusterfs/gv1/brick1/brick 2.2G /data/glusterfs/gv1/brick1/brick/.glusterfs 24M /data/glusterfs/gv1/brick1/brick/scalelite-recordings 16K /data/glusterfs/gv1/brick1/brick/mytute 18M /data/glusterfs/gv1/brick1/brick/.shard 0

Hi, Thanks for your response, please find the xfs_info for each brick on the arbiter below: root at uk3-prod-gfs-arb-01:~# xfs_info /data/glusterfs/gv1/brick1 meta-data=/dev/sdc1 isize=512 agcount=31, agsize=131007 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 =

This pull request contains the XFS filesystem driver for Syslinux. Due to historical reasons (SGI IRIX's design of disk layouts), the first sector in the primary AG on XFS filesystems contains the superblock, which is a problem with BIOSes, since VBRs must be loaded up from the first sector of the active partition. Thus, we needed to handle this issue by putting the Syslinux bootsector

Split up the huge generator/actions.ml into several smaller files. Rich.

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.