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
>>> > ino
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. Russel
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 3.1
On 10/21/2014 03:13 AM, Russell Coker wrote:
On Tue, 21 Oct 2014, Robert White 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 a server with 64
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 wou
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
>> d
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 l
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
On Tue, 21 Oct 2014, 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 ./141
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"
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
On 10/18/2014 04:41 PM, Russell Coker wrote:
On Sun, 19 Oct 2014, Robert White 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 su
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 ./1412233213.M638209P1054
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
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?
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
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-char
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, what happens if you expand
that *546 find one character at a
On Sun, 19 Oct 2014, Robert White 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 "l
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 Sat, 18 Oct 2014, "Michael Johnson - MJ" 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 handle files
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 performance
22 matches
Mail list logo