Understanding why certain chattr attributes are set on directories/files

JockVSJock · 08-19-2016, 11:08 AM

Trying to figure out the how and why here.

There was data imported from one UNIX flavor server (no one seems to remember what it was...maybe Solaris) to a RHEL6 server.

If using the command lsattr, all of the directories/files, have the following attributes set:

Code:

----------I--e-

Or

Code:

-------------e-

According to the man page:

http://linux.die.net/man/1/chattr

Quote:

The 'e' attribute indicates that the file is using extents for mapping the blocks on disk. It may not be removed using chattr(1).

The 'I' attribute is used by the htree code to indicate that a directory is being indexed using hashed trees. It may not be set or reset using chattr(1), although it can be displayed by lsattr(1).

Just wondering if others have seen this and how did these lsattr attributes get set only a certain directory and files.

The reason I'm asking too is that here in the near future I may have to export this data to another server and was wondering if this would impact the move.

I've experimented with setting chattr on files/directories and you are limited on what you can do with it.

thanks

hydrurga · 08-20-2016, 05:50 AM

Assuming that you're using ext 3/4, for the I attribute (htree indexing), the default for a new directory is to use linear addressing, the directory only being converted by the filesystem to use htree indexing when it gets above a certain size. So, those directories marked I should be larger (or will at one point have been larger) than the others.

Do you actually have any files from that origin without the e attribute set?

JockVSJock · 08-20-2016, 07:12 AM

Quote:

Originally Posted by hydrurga

Do you actually have any files from that origin without the e attribute set?

I don't have original files. That was 2 to 3 sys admins ago and the original server that was the source was decommissioned along time ago. I'm just trying to solve the puzzle here.

I'm not familiar with linear addressing, nor is there anyway to tell if the directories were larger in size then their source.

hydrurga · 08-20-2016, 07:34 AM

Quote:

Originally Posted by JockVSJock

I don't have original files. That was 2 to 3 sys admins ago and the original server that was the source was decommissioned along time ago. I'm just trying to solve the puzzle here.

I'm not familiar with linear addressing, nor is there anyway to tell if the directories were larger in size then their source.

Sorry, JvJ, I'm not talking about the original files on the original server, I'm talking about the files you have now that came from that server.

What I'd like to know is, roughly what proportion of files that come from that original server now have the e attribute? All? Some?

Regarding the directories with the I attribute - you should find that those directories you currently have with that attribute will generally have more directory entries than those without it (and thus are using htree hash indexing which is more efficient for larger numbers of directory entries).

Although it is now an old document, this pdf - https://www.kernel.org/doc/ols/2002/...es-425-438.pdf - has a great description of the rationality behind and implementation of htree directory indexing.

Migrating files with these attributes to another server should not be problematic.

JockVSJock · 08-22-2016, 09:14 AM

Trying to get you some numbers here for the "e" attribute. However when trying to run the following (and have to take in account ext4 FS)

Code:

lsattr -R /data | grep -e | wc -l

Keeps timing out, so I'll have to write it up in a cron, however I'm going to guess and say alot of files have the "e" attribute set along with "I" too.

thanks

hydrurga · 08-22-2016, 09:50 AM

Thanks. The reason I ask is that I would expect all the files with attributes to have the 'e' attribute set if extents were in use on the original filesystem.

Just out of interest, do you know what the original filesystem was? Also, what filesystem are you using at the moment and what is the filesystem on the server where you might be moving the files in the future?

No need for the cron (it would be meaningless anyway as the lsattr -R command produces blank lines and headings), just an eyeballed lsattr -R (or a sample thereof) would do fine.

JockVSJock · 08-22-2016, 10:12 AM

Quote:

Originally Posted by hydrurga

do you know what the original filesystem was?

Unknown, that was 2 to 3 sys admins ago and that information is lost...I'm guessing, probably Solaris.

Quote:

Originally Posted by hydrurga

Also, what filesystem are you using at the moment and what is the filesystem on the server where you might be moving the files in the future?

Filesystem is ext4 with RHEL6 on a VM.

We will be moving to a physical server due to certain rules and the OS and filesystem will stay the same.

Quote:

Originally Posted by hydrurga

No need for the cron (it would be meaningless anyway as the lsattr -R command produces blank lines and headings), just an eyeballed lsattr -R (or a sample thereof) would do fine.

I didn't mean cron, I should have said script.

thanks

hydrurga · 08-22-2016, 10:44 AM

Thanks. Just for info, the following should list the ordinary files in the current directory and below which don't have the e attribute set:

Code:

find . -type f -exec lsattr {} \; | grep -v -P "(?<=-)e(?=-)"

JockVSJock · 08-22-2016, 11:01 AM

Thanks for the example, I saw that here:

http://unix.stackexchange.com/questi...-attribute-set

However I'm not sure what the following does:

Code:

"(?<=-)e(?=-)"

However when running it on certain directories, this is the output:

Code:

[root@server directory_A]# find / -type f -exec lsattr {} \; | grep -v -P "(?<=-)e(?=-)"
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/queue.bin
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-3
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-4
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-5
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-6
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-7
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-8
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-12
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-10
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-11
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-9
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-13
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-15
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-17
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-27
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-14
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-16
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-18
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-2
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-20
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-26
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-22
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-25
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-21
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-24
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-23
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sda1
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-0
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-19
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:dm-1
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdx
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdw
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdu
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdv
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/input:event2
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/input:mouse1
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/input:event1
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/input:event3
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sds
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdb
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdm
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdp
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdf
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdq
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sda2
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdh
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sda3
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdc
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdg
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdl
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdi
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sde
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdn
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdo
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdk
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdd
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdr
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdj
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sdt
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/input:event0
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sda
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:sr0
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/net:eth0
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram9
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram8
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram7
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram6
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram3
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram5
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram4
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram15
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram2
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram12
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram14
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram13
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram11
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram10
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:loop6
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:loop5
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:loop2
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:loop3
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:loop0
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:loop7
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram0
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:ram1
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:loop1
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/block:loop4
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/db/serio:serio0
lsattr: Inappropriate ioctl for device While reading flags on /dev/.udev/rules.d/99-root.rules

With that said, I would say the majority of the files found under this directory and sub-directories have the following lsattr attributes set:

Code:

----------I--e-

hydrurga · 08-22-2016, 11:20 AM

I didn't put a 2>/dev/null in there as well, to mute error output, because I assumed that you were going to run it on /data as in the example you gave. Running commands like lsattr recursively on / is only going to generate pain.

There should only be directories with the I attribute set, not ordinary files.

Anyway, the upshot is that you have nothing to worry about and that you should be good to go with transferring those files to the new server, as far as those attributes are concerned anyway.