should be: gluster 3.31b*2* destroying mountpoints?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Resolution:

As Brian noted, and Haris alluded to, these strange dirs are chowned 
this way when a non-running glusterfs is mounted.  When I started the 
gluster volume remotely, they immediately mounted, such that I had the 
same gluster volume mounted on both /gl and /gll (/gll was created so 
I could ignore the odd state of /gl for a while).  I was able to 
umount the gluster vol from /gll and delete it normally.

So now it seems to be working correctly.  

While this might be an edge case, I wonder if this might be detected 
and a relevant error emitted by the client (yes, easy for me to 
say..)..

thanks.

hjm

On Thursday 22 March 2012 14:05:25 Brian Candler wrote:
> On Thu, Mar 22, 2012 at 01:56:49PM -0700, Harry Mangalam wrote:
> >    Previous email had a typo in Subject line.
> 
> What do you mean by "destroying" the mountpoint?
> 
> I have seen those d??????????? entries before (not with gluster).
> IIRC it's when a directory has 'read' but not 'execute' bits set.
> 
> $ mkdir foo
> $ chmod foo/bar
> $ chmod 666 foo
> $ ls -l foo
> ls: cannot access foo/bar: Permission denied
> total 0
> -????????? ? ? ? ?                ? bar

-- 
Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine
[ZOT 2225] / 92697  Google Voice Multiplexer: (949) 478-4487
415 South Circle View Dr, Irvine, CA, 92697 [shipping]
MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps)
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gluster.org/pipermail/gluster-users/attachments/20120322/ef4de234/attachment.htm>


[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux