LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 08-19-2016, 12:08 PM   #1
JockVSJock
Senior Member
 
Registered: Jan 2004
Location: SATX
Distribution: RHEL/CentOS
Posts: 1,233
Blog Entries: 4

Rep: Reputation: 135Reputation: 135
Understanding why certain chattr attributes are set on directories/files


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
 
Old 08-20-2016, 06:50 AM   #2
hydrurga
Senior Member
 
Registered: Nov 2008
Location: Pictland
Distribution: Linux Mint 18.2 MATE
Posts: 3,491
Blog Entries: 2

Rep: Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198
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?
 
Old 08-20-2016, 08:12 AM   #3
JockVSJock
Senior Member
 
Registered: Jan 2004
Location: SATX
Distribution: RHEL/CentOS
Posts: 1,233
Blog Entries: 4

Original Poster
Rep: Reputation: 135Reputation: 135
Quote:
Originally Posted by hydrurga View Post

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.
 
Old 08-20-2016, 08:34 AM   #4
hydrurga
Senior Member
 
Registered: Nov 2008
Location: Pictland
Distribution: Linux Mint 18.2 MATE
Posts: 3,491
Blog Entries: 2

Rep: Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198
Quote:
Originally Posted by JockVSJock View Post
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.
 
Old 08-22-2016, 10:14 AM   #5
JockVSJock
Senior Member
 
Registered: Jan 2004
Location: SATX
Distribution: RHEL/CentOS
Posts: 1,233
Blog Entries: 4

Original Poster
Rep: Reputation: 135Reputation: 135
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
 
Old 08-22-2016, 10:50 AM   #6
hydrurga
Senior Member
 
Registered: Nov 2008
Location: Pictland
Distribution: Linux Mint 18.2 MATE
Posts: 3,491
Blog Entries: 2

Rep: Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198
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.
 
Old 08-22-2016, 11:12 AM   #7
JockVSJock
Senior Member
 
Registered: Jan 2004
Location: SATX
Distribution: RHEL/CentOS
Posts: 1,233
Blog Entries: 4

Original Poster
Rep: Reputation: 135Reputation: 135
Quote:
Originally Posted by hydrurga View Post
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 View Post
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 View Post
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
 
Old 08-22-2016, 11:44 AM   #8
hydrurga
Senior Member
 
Registered: Nov 2008
Location: Pictland
Distribution: Linux Mint 18.2 MATE
Posts: 3,491
Blog Entries: 2

Rep: Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198
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(?=-)"
 
Old 08-22-2016, 12:01 PM   #9
JockVSJock
Senior Member
 
Registered: Jan 2004
Location: SATX
Distribution: RHEL/CentOS
Posts: 1,233
Blog Entries: 4

Original Poster
Rep: Reputation: 135Reputation: 135
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-
 
Old 08-22-2016, 12:20 PM   #10
hydrurga
Senior Member
 
Registered: Nov 2008
Location: Pictland
Distribution: Linux Mint 18.2 MATE
Posts: 3,491
Blog Entries: 2

Rep: Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198Reputation: 1198
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.
 
  


Reply

Tags
chattr, lsattr


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Add/Remove Hidden and ReadOnly attributes from files and directories on vfat filesyst Snigger Linux - Desktop 6 11-11-2015 09:31 AM
Understanding Files and Directories Permissions in Linux. amanpreet Linux - General 3 07-09-2013 09:59 PM
LXer: Change Attributes of a File in Linux using chattr Command LXer Syndicated Linux News 0 05-16-2013 07:50 AM
[SOLVED] how change attributes or remove files with the e attribute set porphyry5 Linux - General 3 07-07-2011 08:16 PM
LXer: Viewing and Changing Ext2/3 File Attributes With chattr and lsattr LXer Syndicated Linux News 0 03-29-2009 07:50 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 10:39 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration