Hello, I am running a file-level backup of an 1.8 mds system. At the moment, I am running the getfattr command as mentioned on page 15-3 in the lustre fs manual. The biggest thing i a noticing, is that the attributes are as large or larger than the actual filesystem. I expect that when converting bits to ascii data, the amount of space used will increase. The question though is "how much"? It doesn''t seem reasonable for the bits to inflate THAT much. --jason Jason Brooks 971-238-3924 brookjas at ohsu.edu<mailto:brookjas at ohsu.edu> Oregon Health Sciences University Center for Spoken Language Understanding -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lustre.org/pipermail/lustre-discuss/attachments/20120919/b2e945c5/attachment.html
Hello, Now that the getfattr operation is done, here are the specs: the mds filesystem (mounted as type ldiskfs) has 7.7 gigabytes in use. however, the getfattr operation produced an ascii file that is 20 gigabytes in size. is this reasonable? On Sep 19, 2012, at 10:06 AM, Jason Brooks wrote: Hello, I am running a file-level backup of an 1.8 mds system. At the moment, I am running the getfattr command as mentioned on page 15-3 in the lustre fs manual. The biggest thing i a noticing, is that the attributes are as large or larger than the actual filesystem. I expect that when converting bits to ascii data, the amount of space used will increase. The question though is "how much"? It doesn''t seem reasonable for the bits to inflate THAT much. --jason Jason Brooks 971-238-3924 brookjas at ohsu.edu<mailto:brookjas at ohsu.edu> Oregon Health Sciences University Center for Spoken Language Understanding _______________________________________________ Lustre-discuss mailing list Lustre-discuss at lists.lustre.org<mailto:Lustre-discuss at lists.lustre.org> http://lists.lustre.org/mailman/listinfo/lustre-discuss Jason Brooks 971-238-3924 brookjas at ohsu.edu<mailto:brookjas at ohsu.edu> Oregon Health Sciences University Center for Spoken Language Understanding -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lustre.org/pipermail/lustre-discuss/attachments/20120919/5a85193a/attachment.html
On 2012-09-19, at 9:36 PM, Jason Brooks wrote:> Now that the getfattr operation is done, here are the specs: > > the mds filesystem (mounted as type ldiskfs) has 7.7 gigabytes in use. > > however, the getfattr operation produced an ascii file that is 20 gigabytes in size. > > is this reasonable?Depends on what you are storing in xattrs and striping. The MDS files have no data in them, so tar will only store the pathname and POSIX attributes. The xattr data will have at least 96 bytes of data * 2 for asciification + any additional data you are storing for ACLs or user xattrs. Cheers, Andreas> On Sep 19, 2012, at 10:06 AM, Jason Brooks wrote: > >> Hello, >> >> I am running a file-level backup of an 1.8 mds system. At the moment, I am running the getfattr command as mentioned on page 15-3 in the lustre fs manual. The biggest thing i a noticing, is that the attributes are as large or larger than the actual filesystem. I expect that when converting bits to ascii data, the amount of space used will increase. The question though is "how much"? It doesn''t seem reasonable for the bits to inflate THAT much. >> >> --jason >> >> >> Jason Brooks >> 971-238-3924 >> brookjas at ohsu.edu >> Oregon Health Sciences University >> Center for Spoken Language Understanding >> >> _______________________________________________ >> Lustre-discuss mailing list >> Lustre-discuss at lists.lustre.org >> http://lists.lustre.org/mailman/listinfo/lustre-discuss > > Jason Brooks > 971-238-3924 > brookjas at ohsu.edu > Oregon Health Sciences University > Center for Spoken Language Understanding > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discussCheers, Andreas -- Andreas Dilger Whamcloud, Inc. Principal Lustre Engineer http://www.whamcloud.com/