XFS_DB

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

 



Developers,

 

I have system with configuration as

RAM : 4G

SWAP: 2G

 

On  this system I had created an XFS file system of size 250 GB, I am using xfs_db utility to  get file mapping( file name and inode number ) information using the daddr & corresponding  File system block number.  

 

/dev/sdd1 : 250G filesystem, 13% (29 G) full, aprox 3.5 million files

 

Steps executed in getting this information is as below :

 

test#  xfs_db -i -c "convert daddr 6612146 fsb" /dev/sdd1

0xc9c96 (826518)

test:~ #  xfs_db -i -c "blockget -n -b 826518" /dev/sdd1

xfs_db: out of memory

 

Utility (xfs_db ) is giving OOM in extracting  block information using “blockget” and in some cases it gives OOM when subcommand “ncheck”of xfs_db.  It is mentioned in the manuals itself that ncheck is memory consuming command. When we analysed the command memory map of ncheck using “pmap”  most of the memory is consumed in heap. It’s not utilized by cache memory.

 

 

Whether xfs_db stores  information of all the blocks  upto the requested block or it maintains its internal structure. When checking the xfs_db codethen found function call like (push_cur()  etc ) whether it is maintaining its own command execution stack.

 

Instead of accessing the device itself can we read the metadump file to get the required information of file mapping with file system block number. Its binary file but is there any utility which reads the metadump file itself instead of file system image. As it is easier to read the metadump file instead of go towards  disk access itself. There is file obfuscation in the file name for 4 characters

 

Whether reading metadump file for getting file mapping with file system block number still consumes same amount of memory or this will not works.

 

Please provide some reference to either eliminate the OOM (in blockget and ncheck) or any other way either related to accessing metadump file in getting the mapping (fsbno to file name or inode number ). As currently finding out the cause of this memory consumption from the source itself whether optimization in finding this mapping information  is possible or not  

 

On finding out solution over the OOM I found reference of xfs_db 64  but there is no 64 bit version of utility available in xfs website either there will be some configuration option or it becomes obsolete.

 

 

 

Thanks & Best Regards

Anshul Kundra

 

 



::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs

[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux