Hi all

I have a requirement to look through a filesystem, identify any files 
that haven't been accessed for 365 days then output this to a file.

Simple right: # find . -atime +365 > file.foo

However, I can't seem to create a file greater than ~32mb (on this 
attempt I get a file of 33249280 bytes). It's a very large filesystem.

Trussing find's PID, I can see that find is still active, and statting 
files.

If I pipe the find output to tee, ( # find . -atime +365 |tee file.foo 
for example ), I get the same issue.

Does anyone have any idea - I'm thinking this might be a limitation with 
find, or my environment maybe. Solaris 9 118558-11 and GNU bash, version 
2.05.0(1)-release (sparc-sun-solaris2.9).

Or, should I forget find, and "find" another way to do this using grep, 
ls etc?

cheers

Sam

Sam Nelson <sun@unix.ms.nospam> wrote:
> I have a requirement to look through a filesystem, identify any files 
> that haven't been accessed for 365 days then output this to a file.

> Simple right: # find . -atime +365 > file.foo

> However, I can't seem to create a file greater than ~32mb (on this 
> attempt I get a file of 33249280 bytes). It's a very large filesystem.

You're saying the 'file.foo' seems to max out at that size?

The size you show is still some 300K short of 32 * 2^20, and 32M isn't a
limit of any part of the filesystem that I'm aware of.

> Trussing find's PID, I can see that find is still active, and statting 
> files.

Yes, but is it write()'ing output?  Thats the only thing that will make
the file increase in size.  What's the return code on the write()?  If
there were a limitation in the filesize, it should have an error code.

Is your filesystem full (doesn't sound like it)?

> If I pipe the find output to tee, ( # find . -atime +365 |tee file.foo 
> for example ), I get the same issue.

Are you sure the output is incorrect?

> Does anyone have any idea - I'm thinking this might be a limitation with 
> find, or my environment maybe. Solaris 9 118558-11 and GNU bash, version 
> 2.05.0(1)-release (sparc-sun-solaris2.9).

> Or, should I forget find, and "find" another way to do this using grep, 
> ls etc?

Nothing you've mentioned so far would suggest that 'find' wasn't a
reasonable solution.  

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

Darren Dunham wrote:
> Sam Nelson <sun@unix.ms.nospam> wrote:
>> I have a requirement to look through a filesystem, identify any files 
>> that haven't been accessed for 365 days then output this to a file.
> 
>> Simple right: # find . -atime +365 > file.foo
> 
>> However, I can't seem to create a file greater than ~32mb (on this 
>> attempt I get a file of 33249280 bytes). It's a very large filesystem.
> 
> You're saying the 'file.foo' seems to max out at that size?
> 
> The size you show is still some 300K short of 32 * 2^20, and 32M isn't a
> limit of any part of the filesystem that I'm aware of.
> 
>> Trussing find's PID, I can see that find is still active, and statting 
>> files.
> 
> Yes, but is it write()'ing output?  Thats the only thing that will make
> the file increase in size.  What's the return code on the write()?  If
> there were a limitation in the filesize, it should have an error code.
> 
> Is your filesystem full (doesn't sound like it)?
> 
>> If I pipe the find output to tee, ( # find . -atime +365 |tee file.foo 
>> for example ), I get the same issue.
> 
> Are you sure the output is incorrect?
> 
>> Does anyone have any idea - I'm thinking this might be a limitation with 
>> find, or my environment maybe. Solaris 9 118558-11 and GNU bash, version 
>> 2.05.0(1)-release (sparc-sun-solaris2.9).
> 
>> Or, should I forget find, and "find" another way to do this using grep, 
>> ls etc?
> 
> Nothing you've mentioned so far would suggest that 'find' wasn't a
> reasonable solution.  
> 

Hi Darren - thanks for the answers: I now have the solution.

The filesystem resides on a netapp cluster, and a snapshot of all data 
was mounted under ".snapshot".

Of course, find was going through the .snapshot, and was taking 4 hours 
to complete.

D'oh!