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

re[2]: xfsdump max file size



Jason,

Thanks for the heads up.  I am running suse 8.0, but with the xfs 1.2 p3 kernel.  

I'm using the original userland tools.

I'm having the same problem, but never noticed.

I'm now trying to install new tools compiled from source.

ftp://oss.sgi.com/projects/xfs/Release-1.2pre5/cmd_tars

I'll let you know if that fixes the problem for me or not.

Greg

>>  Mandy Kirkconnell wrote:

>>  >
>>  > Jason Joines wrote:
>>  >
>>  >> Mandy Kirkconnell wrote:
>>  >>
>>  >>> Jason Joines wrote:
>>  >>>
>>  >>>> What's the maximum file size for a file to be dumped by xfsdump? 
>>  >>>
>>  >>>
>>  >>>
>>  >>> xfsdump doesn't (really) have a maximum file size limitation.  There 
>>  >>> is a maximum file size defined in xfsdump/dump/content.c but it is 
>>  >>> set to the largest theoretical file size, 18 million terabytes.  The 
>>  >>> definition is defined in bytes:
>>  >>>
>>  >>> /* max "unsigned long long int"
>>  >>> */
>>  >>> #define ULONGLONG_MAX   18446744073709551615LLU
>>  >>>
>>  >>> Obviously this maximum limit is impossible to hit, which is why I 
>>  >>> say xfsdump doesn't have a max file size limit.  You should be able 
>>  >>> to dump the biggest possible file you can create.
>>  >>>
>>  >>> There is, however,  a command line option (-z) to set a maximum file 
>>  >>> size for your dump.  This option allows you to specify a maximum 
>>  >>> file size, in kilobytes.   Files over this size will be excluded 
>>  >>> from the dump.
>>  >>>
>>  >> When running a dump with "xfsdump -F -e -f 
>>  >> /local/backup/weekly/sdb3.dmp -l 0 /dev/sdb3" I get the message, 
>>  >> "xfsdump: WARNING: could not open regular file ino 4185158 mode 
>>  >> 0x000081b0: File too large: not dumped".  The file in question is 5.0 
>>  >> GB.
>>  >>
>>  >> Jason
>>  >> ===========
>>  >>
>>  > xfsdump does not set EFBIG (errno 27) anywhere.  It looks like the 
>>  > error is coming from the filesystem on the first attempt to open the 
>>  > file. What version of xfs are you running?  Are you using the released 
>>  > version of xfsdump, or have you built your own copy?
>>  >
>>  > Perhaps you could also use xfs_db to look at the extents of the file:
>>  >
>>  > # xfs_db -r /dev/sdb3
>>  > xfs_db:  inode 4185158 p
>>  >
>>  > We are able to dump a file of 4.5 GB without hitting the error.  
>>  > Perhaps we can figure out what's different between our environments 
>>  > and go from there.
>>  >
>>  Actually, I'm not quite sure what version of xfs it is.  How do I 
>>  tell?  I am using a 2.4.18 kernel compiled by SuSE.  I installed and 
>>  looked at the source for this kernel but couldn't find anything that 
>>  said what version of xfs it is.  My xfsdump version is version 3.0.  It 
>>  is from a SuSE rpm as well. 

>>  xfs_db gave:
>>  # xfs_db -r /dev/sdb3
>>  xfs_db: inode 4185158
>>  xfs_db: p
>>  core.magic = 0xfeff
>>  core.mode = 0
>>  core.version = 4
>>  core.format = 0 (dev)
>>  core.uid = 0
>>  core.gid = 0
>>  core.atime.sec = Wed Dec  6 15:33:04 1916
>>  core.atime.nsec = -1818818560
>>  core.mtime.sec = Mon Dec 14 15:16:30 1992
>>  core.mtime.nsec = 1140850688
>>  core.ctime.sec = Tue Feb  6 19:52:21 1973
>>  core.ctime.nsec = -1674700016
>>  core.size = -7811766231833445970
>>  core.nblocks = 5764888998212337664
>>  core.extsize = 201326592
>>  core.nextents = 16777216
>>  core.naextents = 26624
>>  core.forkoff = 0
>>  core.aformat = 0 (dev)
>>  core.dmevmask = 0xf000000
>>  core.dmstate = 28672
>>  core.newrtbm = 0
>>  core.prealloc = 0
>>  core.realtime = 0
>>  core.gen = 83886080
>>  next_unlinked = 2483027968
>>  u.dev = 0x6000000
>>  xfs_db: q


>>  Jason
>>  ===========