>>>> Steve Lord <lord@xxxxxxx> 08/08/2003 11:56:14 PM >>>
>On Fri, 2003-08-08 at 01:12, Scott Fagg wrote:
>> >>>> Nathan Scott <nathans@xxxxxxx> 08/08/2003 3:03:45 PM >>>
>> >For some strange reason we are trying to read at AG blk 0 for that
>> >inode, which is wrong - block zero in an AG holds the SB/AGF/AGI/
>> >AGFL for that allocation group. Its not clear if this is due to
>> >the EA data on disk pointing to that block, or a bug in the kernel
>> >code. The tools not finding anything suggests to me a kernel bug,
>> >not sure where though...
>> So what should i do to generate more debug info ?
>> Not sure if it helps, but this sequence of events might give a clue :
>> - run 'find' on the XFS vol
>> - it hits a nasty inode and trigges the kernel message i see.
>> - track down the inode mentioned and remove it and it's parent directory
>> - run 'find' again .. no errors triggered
>> - copy heaps of files back to the XFS vol and the error will probably occur
>> again a couple of times, even if i'm copying 1000's of files.
>> - backup files ( except faulty inodes )
>> - re-format XFS parition
>> - copy files back
>> - .. no errors occur .. until the volume fills up again.
>Do you have some examples of the type of ACL setup you have on these
Relatively simple ones ( i thought ).
getfacl returns :
# file: 2003-07-27 ( <- actually a directory in this example )
# owner: slb
# group: slb
I've been applying these permissions with :
setfacl -dm u:sf:rwx,g::rwx,o::r-x,m::rwx 2003-07-27
setfacl -m u:sf:rwx,g::rwx,o::r-x,m::rwx 2003-07-27
setfacl -R -dm u:sf:rwx,g::rwx,o::r-x,m::rwx 2003-07-27
setfacl -R -m u:sf:rwx,g::rwx,o::r-x,m::rwx 2003-07-27
As a bit of background, the server in question is a backup server, at
the end of each day i do an incremental copy of files to it from
another box. Makes for around 10GB per day, and perhaps 5000 files.
Worst case actually involved 80,000 files. The volume is 170GB and
would have 100,000's of files. ( is there quick way to count files
on a volume ? ) 'find | wc' takes ages
>The problem may well be down in dealing with large numbers of them,
>or large sized acls.
The large numbers i could understand, but i thought my ACLs were
relatively simple. I'm only trying to ensure that 2-3 users have full
access to all files.
>Steve Lord voice: +1-651-683-3511
>Principal Engineer, Filesystem Software email: lord@xxxxxxx
Scott Fagg <scott.fagg@xxxxxxxxxxx>
(07) 3023 6000