Goffredo Baroncelli posted on Tue, 21 Oct 2014 18:40:19 +0200 as
excerpted:
On 10/21/2014 11:50 AM, Duncan wrote:
Goffredo Baroncelli posted on Mon, 20 Oct 2014 22:21:04 +0200 as
excerpted:
[...]
Could this be related to the inode overflow in 32 bit system (see
inode_cache options) ?
Goffredo Baroncelli posted on Mon, 20 Oct 2014 22:21:04 +0200 as
excerpted:
On 10/20/2014 07:37 PM, Robert White wrote:
On 10/18/2014 04:41 PM, Russell Coker wrote:
[...]
Also you said that you are using a 32bit user space copied from
another server under a 64bit kernel. Is the ls command a
On Tue, 21 Oct 2014, Zygo Blaxell zblax...@furryterror.org wrote:
On Mon, Oct 20, 2014 at 04:38:28AM +, Duncan wrote:
Russell Coker posted on Sat, 18 Oct 2014 14:54:19 +1100 as excerpted:
# find . -name *546
./1412233213.M638209P10546 # ls -l ./1412233213.M638209P10546 ls:
cannot
On Tue, 21 Oct 2014 09:50:37 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:
(FWIW I wish that mount option would just go away as it would definitely
remove an invitation to a Russian roulette party with their data for the
unwary, but I suppose there's someone paying some bills somewhere that
I've just upgraded the Dom0 (NFS server) from 3.16.3 to 3.16.5 and it all
works.
Prior to upgrading the Dom0 I had the same problem occur with different file
names. All the names in question were truncated names of files that exist.
It seems that 3.16.3 has a bug with NFS serving files with
Roman Mamedov posted on Tue, 21 Oct 2014 16:16:11 +0600 as excerpted:
On Tue, 21 Oct 2014 09:50:37 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:
(FWIW I wish that mount option would just go away as it would
definitely remove an invitation to a Russian roulette party with their
data for
Russell Coker posted on Tue, 21 Oct 2014 21:13:29 +1100 as excerpted:
I don't know what
space_cache is about, is that something the kernel adds automatically?
Yes, space_cache is the default.
Apparently early in space_cache history you had to mount with space_cache
once, and the kernel
On 10/21/2014 03:13 AM, Russell Coker wrote:
On Tue, 21 Oct 2014, Robert White rwh...@pobox.com wrote:
What happens if you stop the Xen domain for the mail server and then
mount the disks into a native 64bit environment and then ls the file name?
The filesystem in question is NFS mounted from
On 10/21/2014 03:42 AM, Russell Coker wrote:
I've just upgraded the Dom0 (NFS server) from 3.16.3 to 3.16.5 and it all
works.
Prior to upgrading the Dom0 I had the same problem occur with different file
names. All the names in question were truncated names of files that exist.
It seems that
On 10/21/2014 11:50 AM, Duncan wrote:
Goffredo Baroncelli posted on Mon, 20 Oct 2014 22:21:04 +0200 as
excerpted:
[...]
Could this be related to the inode overflow in 32 bit system (see
inode_cache options) ? If so running a 64bit ls -i should work
Good point. Russell might just
On Mon, Oct 20, 2014 at 04:38:28AM +, Duncan wrote:
Russell Coker posted on Sat, 18 Oct 2014 14:54:19 +1100 as excerpted:
# find . -name *546
./1412233213.M638209P10546 # ls -l ./1412233213.M638209P10546 ls: cannot
access ./1412233213.M638209P10546: No such file or directory
Does
On 2014-10-20 09:02, Zygo Blaxell wrote:
On Mon, Oct 20, 2014 at 04:38:28AM +, Duncan wrote:
Russell Coker posted on Sat, 18 Oct 2014 14:54:19 +1100 as excerpted:
# find . -name *546
./1412233213.M638209P10546 # ls -l ./1412233213.M638209P10546 ls: cannot
access
On 10/20/2014 07:37 PM, Robert White wrote:
On 10/18/2014 04:41 PM, Russell Coker wrote:
[...]
Also you said that you are using a 32bit user space copied from
another server under a 64bit kernel. Is the ls command a 32 bit
executable then?
Could this be related to the inode overflow in 32 bit
Duncan posted on Sun, 19 Oct 2014 05:37:36 + as excerpted:
Russell Coker posted on Sun, 19 Oct 2014 10:41:41 +1100 as excerpted:
# find . -name *546 -exec rm {} \;
rm: cannot remove `./1412233213.M638209P10546': No such file or
directory
Going with the non-printable-character theory,
Hiya Russell,
On Sat, 18 Oct 2014 02:54:19 PM Russell Coker wrote:
# find . -name *546
./1412233213.M638209P10546
# ls -l ./1412233213.M638209P10546
ls: cannot access ./1412233213.M638209P10546: No such file or directory
Does:
find . -name *546 -ls
work at all?
--
Chris Samuel :
Russell Coker posted on Sat, 18 Oct 2014 14:54:19 +1100 as excerpted:
# find . -name *546
./1412233213.M638209P10546 # ls -l ./1412233213.M638209P10546 ls: cannot
access ./1412233213.M638209P10546: No such file or directory
Does your mail server do a lot of renames? Is one perhaps stuck? If
On Sat, 18 Oct 2014, Michael Johnson - MJ m...@revmj.com wrote:
The NFS client is part of the kernel iirc, so it should be 64 bit. This
would allow the creation of files larger than 4gb and create possible
issues with a 32 bit user space utility.
A correctly written 32bit application will
On 10/17/2014 08:54 PM, Russell Coker wrote:
# find . -name *546
./1412233213.M638209P10546
# ls -l ./1412233213.M638209P10546
ls: cannot access ./1412233213.M638209P10546: No such file or directory
Any suggestions?
Does ls -l *546 show the file to exist? e.g. what happens if you use
the
On Sun, 19 Oct 2014, Robert White rwh...@pobox.com wrote:
On 10/17/2014 08:54 PM, Russell Coker wrote:
# find . -name *546
./1412233213.M638209P10546
# ls -l ./1412233213.M638209P10546
ls: cannot access ./1412233213.M638209P10546: No such file or directory
Any suggestions?
Does ls
I have a system running the Debian 3.16.3-2 AMD64 kernel for the Xen Dom0 and
the DomUs.
The Dom0 has a pair of 500G SATA disks in a BTRFS RAID-1 array. The RAID-1
array has some subvols exported by NFS as well as a subvol for the disk images
for the DomUs - I am not using NoCOW as
20 matches
Mail list logo
