similar to: Request For Opinions: what to do about the synthetic statfvs "tweak"?

hi guys,   happy new year!!!  I encountered  a problem when we used virt-df command to display my guest disks useage. the virt-df command from pkg libguestfs-tools-c-1.36.3-6.el7_4.3.x86_64,version is  virt-df --version : virt-df 1.36.3rhel=7,release=6.el7_4.3,libvirt the output in guest with the method referred in http://libguestfs.org/virt-df.1.html#STATVFS NUMBERS is:

An issue was found with the netBeans installer where the installation was failing on a large ZFS filesystem. This resulted in CR 6560644 (zfs statvfs f_frsize needs work). The issue is that large filesystems can cause EOVERFLOW on statvfs() calls. This behavior is documented in the statvfs(2) man page, but I think we can do better. The problem was initially reported against ZFS, and my first fix

hi Jones, Thanks for your reply. At 2018-01-04 19:41:27, "Richard W.M. Jones" <rjones@redhat.com> wrote: >On Thu, Jan 04, 2018 at 12:58:40PM +0800, Chen Fan wrote: >[In guest] >> python -c 'import os; s = os.statvfs ("/"); print s' >> posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=5886149, >> f_bfree=4802342, f_bavail=4802342,

common/mlutils: Unix_utils.StatVFS.statvfs: This commit implements a full-featured binding for the statvfs(3) function. We then use this to reimplement the daemon statvfs API in OCaml. Note that the Gnulib fallback is fixed in this commit. It previously referenced non-existent field names in the fs_usage struct. --- common/mlutils/unix_utils-c.c | 138 ++++++++++++++++++++++++++++---

It started out as "this'll be just a simple fix ..." and turned into something a bit over-engineered in the end. Here it is anyway. Rich.

v2 -> v3: - Drop gnulib fallback.

v1 -> v2: - Removed the f_type field from StatVFS.statvfs structure. - New function StatVFS.filesystem_is_remote, written in C. [Thinking about it, this should probably be called ?is_network_filesystem?, but I can change that before pushing]. - Use statvfs instead of fstatvfs, and statfs instead of fstatfs. - Rejigged the comments in builder/builder.ml to make them simpler

I'm observing that the new staged installation in R 3.6.0 can produce: mv: cannot move ?/home/alice/R/x86_64-pc-linux-gnu-library/3.6/00LOCK-codetools/00new/codetools? to ?/home/alice/R/x86_64-pc-linux-gnu-library/3.6/codetools?: File exists ERROR: moving to final location failed on some file systems. # EXAMPLE $ R --vanilla R version 3.6.0 (2019-04-26) -- "Planting of a Tree"

From: Steve Langasek <vorlon@debian.org> Fix the definition of struct statfs64, required for run-init to work on alpha. verified to have no regressions on amd64. Signed-off-by: maximilian attems <janitor@sternwelten.at> Signed-off-by: Frederik Sch?ler <fschueler-guest@costa.debian.org> --- klibc-1.1.1.orig/include/sys/vfs.h +++ klibc-1.1.1/include/sys/vfs.h @@ -32,17 +32,17

On Thu, Jan 04, 2018 at 12:58:40PM +0800, Chen Fan wrote: [In guest] > python -c 'import os; s = os.statvfs ("/"); print s' > posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=5886149, > f_bfree=4802342, f_bavail=4802342, f_files=23556096, > f_ffree=23435372, f_favail=23435372, f_flag=4096, f_namemax=255) > > python -c 'import os; s = os.statvfs

On Tue, May 7, 2019 at 9:05 AM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > Thanks for the report. According to my reading, this use of "mv" is ok > and the renameat2() call which the invocation of "mv" leads to is also > ok and allowed by POSIX in this context. It could only fail with EEXIST > if the target directory (path/pkg) was not empty.

I created a 1TB RAID1. So far it is just for testing, no important data on there. After a reboot, I tried to mount it again # mount /dev/mapper/vg00-btrfsvol0_0 /mnt/btrfs0 mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg00-btrfsvol0_0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or

please pull from git://charm.itp.tuwien.ac.at/mattems/klibc/.git branch maks. arch/mips/klibc/archconfig.h | 3 +++ klibc/sysconfig.h | 10 ++++++++++ sys/vfs.h | 17 +++++++++++++++++ 3 files changed, 30 insertions(+)

I believe that there is one more patch required for a successful build on Tru64: # diff ./src/lib/mountpoint.c.orig ./src/lib/mountpoint.c 60a61,63 > #ifdef __osf__ > point_r->type = p_strdup(pool, getvfsbynumber(buf.f_type)); > #else 62c65,66 < point_r->block_size = buf.f_bsize; --- > #endif > point_r->block_size = buf.f_bsize; Cheers

I'd like to propose the following extensions to the SFTP protocol. - statvfs operation - atomic rename (just plain POSIX rename() without the existence check) These are the most requested features in SSHFS, which need support in sftp-server too. They could be added to the current protocol with the SSH_FXP_EXTENDED message type. Here's a patch implementing the statvfs operation. It

To summarise: >[In guest] > python -c 'import os; s = os.statvfs ("/boot"); print s' > posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=127147, > f_bfree=93815, f_bavail=93815, f_files=512000, f_ffree=511626, > f_favail=511626, f_flag=4096, f_namemax=255) >[From the host via libguestfs] > # sudo guestfish --ro -d rpm-build-for-7.2 -i statvfs /boot

Thanks for the report.? According to my reading, this use of "mv" is ok and the renameat2() call which the invocation of "mv" leads to is also ok and allowed by POSIX in this context. It could only fail with EEXIST if the target directory (path/pkg) was not empty. So far I've not been able to reproduce but we could fall back to copy like on Windows. Best Tomas On

On 5/7/19 6:18 PM, Henrik Bengtsson wrote: > On Tue, May 7, 2019 at 9:05 AM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: >> Thanks for the report. According to my reading, this use of "mv" is ok >> and the renameat2() call which the invocation of "mv" leads to is also >> ok and allowed by POSIX in this context. It could only fail with EEXIST

The latest version that Western Digital has shipped with the My cloud devices accesses the disk about twice a minute. The access to /dev/sda2 is causing the system to keep the disk from going into standby mode. I don't understand the call to quotactl every minute when no one is trying to access the share. An strace of one of the processes shows the following: poll([{fd=13,

Hello, I have a DELL MD3000i, and a couple of servers that I want to connect to the array. I have setup the main server with CentOS 5. - 2.6.18-53.el5 x86_64 - ocfs2-tools-1.2.7-1.el5 - ocfs2console-1.2.7-1.el5 - ocfs2-2.6.18-53.el5-1.2.8-2.el5 # Kernel Module And two OpenSuSe 10.3 Servers - 2.6.22.5-31-default x86_64 - ocfs2-tools-1.2.6-18 - ocfs2console-1.2.6-18 The module has been already