similar to: File locking for large file systems

I have a intel box running redhat 8.I am trying to use large file support in ext3 but have hit the following snag. I have a file that was created using lfs : rw-r--r-- 1 amitm amitm 2147491330 Nov 13 10:16 /home/amitm/storage/cam_n2_q1/atvdatacam_n2_q1.dat I write a simple program to do the basic file I/O but I hit a snag doing the seek. int main(void) { int fd; int result;

While going through an old todo list I found that these patches had fallen by the way-side. About a year ago I initiated a discussion[1] with the Linux kernel folks regarding the lack of any useable fadvise support on the kernel side. As a result, I was observing extremely poor performance on my server after backup as executable pages were being swapped out in favor of data waiting to be flushed

Here's an assortment of build and run-time fixes for various architectures that we've applied in Debian. Ben. Aurelien Jarno (1): ppc64: fix struct stat Ben Hutchings (2): MIPS: Update archfcntl.h syscalls: Override detection of direct socket syscalls on i386, m68k, s390 Helge Deller (1): Add pread and pwrite 32bit syscall wrappers for parisc Mauricio Faria de Oliveira

Hello, This series introduces arm64 support to klibc. I've rebased the work from Neil Williams and Anil Singhar into the following three patches. Most of the code changes are due to new syscall implementations being needed for arm64 as a only a minimal set of syscalls are defined in the arm64 kernel. This series is to be applied against the latest klibc, just after 25a66fa README.klibc:

Hello, Here is V2 of the arm64 support for klibc patch set. Notable changes since the original series: * fp regs dropped from setjmp/longjmp * chmod, lstat and stat re-implemented with *at functions. * open64 merged into open. As with the original, this series is to be applied against the latest klibc, just after 25a66fa README.klibc: update build information V2 has been tested on x86_64

When I run configure on either a DU server running 4.0f or a DU client running 4.0d, I receive the following error: ERROR: No locking available. Running Samba would be unsafe configure: error: summary failure. Aborting config Most directories are mounted using nfs v2 or nfs v3. rpc.lockd and rpc.statd are running on servers and clients. The rpcinfo -p command shows nlockmgr and llockmgr

Hiya, I can see it's a regular subject on this list. I, like others wanted to use rsync to synchronise two block devices (as it happens one lvm volume and one nbd device served by qemu-img on a remote host from a qcow2 disk image so that I can keep the old versions) As I couldn't find any report of it being done successfully, I'm just sharing my findings as it might benefit others.

On Sat, Apr 22, 2006 at 06:15:31PM +0100, Daniel J Blueman wrote: > As a test, I changed the opening of the locking.tdb and brlock.tdb > files to use the TDB_INTERNAL flag, avoiding use of the fcntl(F_SETLK) > syscall for locking individual database records. Performance was a lot > snappier, with quite a bit less system time used. > > What is the scope of implementing shared

Hi, A bug I've had reported is that scp doesn't work with large files (Debian bug number 106809). The problem seems to be scp.c:504: if ((fd = open(name, O_RDONLY, 0)) < 0) Is there some reason why making that if ((fd = open(name, O_RDONLY|O_LARGEFILE, 0)) < 0) would break things? It seems a simple fix to me... Thanks, Matthew -- "At least you know where you are

Jim@Morris.net wrote: > I have finally tracked down the reason I am experiencing problems with > DBase files on Samba file servers - initially Redhat 6, and now on > Caldera OpenLinux 2.2 as well. Great debugging work ! > The DOS client code uses a DBase library called CodeBase to access the > DBase files. When a record is appended to a file, the underlying C > code does the

Hi, is there a DD-accessible porterbox somewhere (slow would be ok, as this is smallish software) with an up-to-date sid (enough to install the recently-built libklibc-dev 2.0~rc5-1 and all other B-D of mksh 40.9.20120518-1, as well as strace and gdb-minimal)? Similarily to http://www.zytor.com/pipermail/klibc/2012-May/003229.html I found klibc-compiled programmes on Alpha to fail (SIGSEGV

Hello, I am running HP-UX 11 with Samba 2.2.5 binaries for HPUX and I keep getting the error that Samba can't find the unicode_map.xxx file. Well, I notice that all I have in /usr/local/samba/lib/codepages is codepage type files, not unicode. Why do the binaries not include a compiled make_unicodemap? I did download the source and found the .c file for the command. When I try to run

From: Heiko Carstens <heiko.carstens@de.ibm.com> vfork support for s390/s390x. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> --- diff -purN a/usr/klibc/SYSCALLS.def b/usr/klibc/SYSCALLS.def --- a/usr/klibc/SYSCALLS.def 2006-06-07 09:44:33.000000000 +0200 +++ b/usr/klibc/SYSCALLS.def 2006-06-07 13:01:54.000000000 +0200 @@ -28,7 +28,7 @@ void _exit,exit::_exit(int) ; A

We are trying to enable large file support for everything built for ARM on ChromeOS and openssh uses mkstemp which has a 64-bit version for compatibility with open64. When looking into enabling the large file support flags, I noticed: `void start_progress_meter(const char *, off_t, off_t *);` in progressmeter.h which would have different ABIs with and without large file support. You all

On Wed, 22 Mar 2023, Allen Webb wrote: > We are trying to enable large file support for everything built for > ARM on ChromeOS and openssh uses mkstemp which has a 64-bit version > for compatibility with open64. When looking into enabling the large > file support flags, I noticed: > > `void start_progress_meter(const char *, off_t, off_t *);` > > in progressmeter.h

I'm porting the musl C library to ARM Thumb. It looks like inline asm is failing in some cases. Here's one: The lseek system call looks like this: ... off_t result; return syscall(SYS__llseek, fd, offset>>32, offset, &result, whence) ? -1 : result; ... Which eventually goes through this macro: static inline long __syscall5(long n, long a, long b, long c,

Lately I'm seeing bizarre problems with the SAMBA server I'm using in production. For no rhyme or reason the connections get dropped, the same set of users who previously were able to access the shares, now get permission denied. Users (not all but some) are having trouble opening the folders, files and so on. This was not the case few days ago, it started happening lately with amazing

re this is a patch against samba-2.2.12p0 and adds support for updating utmp on bsds. code similarly ripped from openbsd's ftpd (; cu -- paranoic mickey (my employers have changed but, the name has remained) --- utmp.c Thu Aug 12 14:24:20 2004 +++ /home/mickey/utmp.c Wed Mar 30 15:51:40 2005 @@ -261,6 +261,7 @@ } #ifndef HAVE_PUTUTLINE +#include <ttyent.h>

Hello Arjen van der Meijden, on xapian-discuss you mentioned that your Xapian installation has got up to 15 GB database size. Can you tell me about the largest index filesize you got? According to <http://xapian.org/docs/scalability.html>, it seems that the quartz database filesize is limited only by the OS and file system. Can you confirm from your experience that there is no 2GB limit?

re i have posted this before but received no response... is there anybod reading on this address? cu ----- Forwarded message (env-from mickey) ----- re this is a patch against samba-2.2.12p0 and adds support for updating utmp on bsds. code similarly ripped from openbsd's ftpd (; cu -- paranoic mickey (my employers have changed but, the name has remained) --- utmp.c Thu Aug 12