LINUX.ORG.RU
Форум — Admin  

cp и атрибуты файла


0

1

если сделать: cp -ax f1 f2

то modify_time не меняется, а created ставится текущим. А есть ли способ и перенести значение данного атрибута ?

★★☆☆
← Перенос контейнеров с virtuozzo на openvz
squid закрыть зеркала ? →

Не пробовал, но может:

       --preserve[=ATTR_LIST]
              preserve the specified attributes (default: mode,ownership,timestamps), if possible additional attributes: context, links, xattr, all

Смотря что подразумевается под timestamps - create и access или весь набор create+modify+access.

Pinkbyte ★★★★★
()

то modify_time не меняется, а created ставится текущим. А есть ли способ и перенести значение данного атрибута ?

а что это за ФС, в которой есть created time?

drBatty ★★
()

ctime это не время создания файла, а время изменения метаданных, а они таки изменились (создались заново).

anonymous
()
Ответ на: комментарий от Pinkbyte

Смотря что подразумевается

у него и так уже -a

-a, --archive same as -dR --preserve=all

drBatty ★★
()

Утверждается, что нет способа изменит crtime (birthtime) http://lists.gnu.org/archive/html/bug-coreutils/2011-02/msg00057.html

только если изменить системное время в момент запуска cp.

Когда то давно, когда мне надо было менять ctime, я писал программу, которая запускает по числу процессоров в системе потоки с приоритетом реального времени (тем самым приостонавливает выполнение остальных задач), переводит системное время, «трогает» файл и переводит время обратно.

Хотя википедия утверждает, что тайм-штампы в ext4 хранятся с точностью до наносекунды, поэтому не уверен, что мой подход сработает.

mky ★★★★★
()
Ответ на: комментарий от mky

Утверждается, что нет способа изменит crtime (birthtime) http://lists.gnu.org/archive/html/bug-coreutils/2011-02/msg00057.html

какой смысл менять cRtime, если это время РОЖДЕНИЯ файла? Как его в принципе-то изменить? Если можно, то какое это нафиг «рождение»?

Хотя википедия утверждает, что тайм-штампы в ext4 хранятся с точностью до наносекунды

тут вика не врёт. 

$ stat ~
  Файл: «/home/drb»
  Размер: 4096      	Блоков: 8          Блок В/В: 4096   каталог
Устройство: 807h/2055d	Inode: 392449      Ссылки: 57
Доступ: (0700/drwx------)  Uid: ( 1000/     drb)   Gid: (  100/   users)
Доступ: 2013-04-15 16:53:13.372205353 +0400
Модифицирован: 2013-04-15 16:53:13.353205353 +0400
Изменён: 2013-04-15 16:53:13.353205353 +0400
 Создан: -

drBatty ★★
()
Ответ на: комментарий от mky

А debugfs на файл на ext4 у вас показывает crtime (время создания)?

в фичах? нет

Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

или где?

drBatty ★★
()
Ответ на: комментарий от drBatty

В команде ″stat″ внутри debugfs. Допустим: 

debugfs -R "stat /drb" /dev/sda7
если у вас ″/home″ отдельным разделом и на /dev/sda7.

А то в интернете куча наслоений, что stat вобще пока не умеет crtime, что для получения crtime нужен новый системный вызов xstat(). И вобще не понятно, с самого ли начала существования ext4 там есть этот самый crtime или его сделали относительно недавно.

mky ★★★★★
()
Ответ на: комментарий от mky

Сейчас получилось такое, что если создавать ext4 командой:

mke2fs -t ext4 /dev/loop3

(loop3 — файл в 10 Мбайт), то crtime не будет.

А если добавить опцию ″-I 256″, то размер inode будет 256 байт, в выводе tune2fs будет поле ″Required extra isize: 28″ и в выводе debugfs появится этот самый crtime.

mky ★★★★★
()
Ответ на: комментарий от mky

УМВР 

# debugfs /dev/sda7 
debugfs 1.42.7 (21-Jan-2013)
debugfs:  stat /drb/t
Inode: 438677   Type: regular    Mode:  0123   Flags: 0x80000
Generation: 1864673935    Version: 0x00000000:00000001
User:     0   Group:     0   Size: 3
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x516c33e6:3b7f2c10 -- Mon Apr 15 21:07:50 2013
 atime: 0x516c3400:b183813c -- Mon Apr 15 21:08:16 2013
 mtime: 0x516c33de:5b34de58 -- Mon Apr 15 21:07:42 2013
crtime: 0x516c3361:476b4784 -- Mon Apr 15 21:05:37 2013
Size of extra inode fields: 28
EXTENTS:
(0):3794825
видать да, crtime только debugfs stat умеет, простая stat(1) не может.

что не удивительно, ибо такого поля нет: 

           struct stat {
               dev_t     st_dev;     /* ID of device containing file */
               ino_t     st_ino;     /* inode number */
               mode_t    st_mode;    /* protection */
               nlink_t   st_nlink;   /* number of hard links */
               uid_t     st_uid;     /* user ID of owner */
               gid_t     st_gid;     /* group ID of owner */
               dev_t     st_rdev;    /* device ID (if special file) */
               off_t     st_size;    /* total size, in bytes */
               blksize_t st_blksize; /* blocksize for file system I/O */
               blkcnt_t  st_blocks;  /* number of 512B blocks allocated */
               time_t    st_atime;   /* time of last access */
               time_t    st_mtime;   /* time of last modification */
               time_t    st_ctime;   /* time of last status change */
           };
(man 2 stat)

И вобще не понятно, с самого ли начала существования ext4 там есть этот самый crtime или его сделали относительно недавно.

в ext3 не было, в ext4 тоже не было ЕМНИП. Сейчас видать сделали.

drBatty ★★
()
Ответ на: комментарий от mky

А если добавить опцию ″-I 256″, то размер inode будет 256 байт, в выводе tune2fs будет поле ″Required extra isize: 28″ и в выводе debugfs появится этот самый crtime.

у меня по дефолту так ибо в конфиге mkfs

	ext4 = {
		features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
		auto_64-bit_support = 1
		inode_size = 256
	}
drBatty ★★
()
Ответ на: комментарий от drBatty

Сейчас сделал ext4 размером побольше (1 Гбайт), там по умолчанию получил inode 256 байт, как написано в man'e. А когда делал 10 Мбайт, размер inode по умолчанию 128 байт.

А про команду stat вобще не понятно. Вот http://lists.gnu.org/archive/html/coreutils/2011-10/msg00071.html получается, что уже 1,5 года прошло, а xstat() так и не появился в ванильном ядре?

mky ★★★★★
()
Ответ на: комментарий от mky

Сейчас сделал ext4 размером побольше (1 Гбайт), там по умолчанию получил inode 256 байт, как написано в man'e. А когда делал 10 Мбайт, размер inode по умолчанию 128 байт.

дык в том же конфиге: 

        small = {
                blocksize = 1024
                inode_size = 128
                inode_ratio = 4096
        }
открой /etc/mke2fs.conf и удивись.

А про команду stat вобще не понятно. Вот http://lists.gnu.org/archive/html/coreutils/2011-10/msg00071.html получается, что уже 1,5 года прошло, а xstat() так и не появился в ванильном ядре?

дык и crtime тоже только недавно появился. Вангую, что в 3.8, или в 3.7 максимум. Можно changelog посмотреть, но мне лениво. ИМХО ненужный штамп. Полтора года назад его ЕМНИП вообще не было в апстриме, хотели в тестинге сделать.

drBatty ★★
()
Ответ на: комментарий от drBatty

Обнаружил, что в CentOS 5 есть crtime. Правда в ванильном 2.6.18 его нет, оно появляется из файла с именем linux-2.6-fs-ext4-2-6-27-rc3-upstream-codebase.patch. Но 2.6.27-rc3, а не 3.8.

открой /etc/mke2fs.conf и удивись.

Да, есть такое. Особенно радует, что там есть «[ext4]», но это не ″-t ext4″, а ″-T ext4″.

Но, главное, что в man'е не написано, что crtime и dtime требует 256 байт, там такая расплывчатая фраза:

In kernels after 2.6.10 and some earlier vendor kernels it is possible to utilize inodes larger than 128 bytes to store extended attributes for improved performance.

И как crtime связан с улучшением производительности не понятно :-)

mky ★★★★★
()
Ответ на: комментарий от mky

Обнаружил, что в CentOS 5 есть crtime. Правда в ванильном 2.6.18 его нет, оно появляется из файла с именем linux-2.6-fs-ext4-2-6-27-rc3-upstream-codebase.patch. Но 2.6.27-rc3, а не 3.8.

дык это бэкпорт очевидно из 3.х в 2.6. Там у вас раньше в вашем CentOS5 вообще ext4 не было, вот - сделали.

Но, главное, что в man'е не написано, что crtime и dtime требует 256 байт, там такая расплывчатая фраза:

а у вас всегда так: фиче бекпортировали, а ман забыли. Вот как у меня

      -I inode-size
              Specify  the size of each inode in bytes.  mke2fs creates 256-byte inodes by default.  In kernels after 2.6.10 and
              some earlier vendor kernels it is possible to utilize inodes larger than 128 bytes to  store  extended  attributes
              for  improved  performance.   The  inode-size  value  must be a power of 2 larger or equal to 128.  The larger the
              inode-size the more space the inode table will consume, and this reduces the usable space in  the  filesystem  and
              can  also  negatively  impact  performance.  Extended attributes stored in large inodes are not visible with older
              kernels, and such filesystems will not be mountable with 2.4 kernels at all.  It is not possible  to  change  this
              value after the filesystem is created.

И как crtime связан с улучшением производительности не понятно

crtime наверное никак. Но сами по себе расширенные атрибуты использовать можно для многого. Если ты что-то сделал с файлом, то можно изменить его атрибут, и тогда второй раз это что-то делать уже не надо. Возможно, в больших инодах можно хранить небольшие пользовательские xattr, которые можно задавать по своему произволу (помниться я задавал md5sum в xattr, что позволило мне считать её всего один раз, а потом очень быстро проверять файлы на их совпадение, без побайтового сравнения. Конечно можно было-бы отдельным файлом, но так получилось ещё быстрее, учитывая, что всего фалов было ОЧЕНЬ много). Хотя возможно я ошибаюсь, и речь идёт о других атрибутах.

PS: dtime ЕМНИП и в ext3 есть, там стандартно 4 timestamp'а, хотя в структуре stat всего 3. Но в структуре inode именно 4. Т.е. это старый и добрый атрибут, которые, насколько мне известно, нигде не используется (хотя можно например отсылать на SSD команду TRIM не просто для удалённых файлов, а для тех из них в первую очередь, которые удалены очень давно, и уже точно не нужны. Но может так оно и есть).

drBatty ★★
()
Ответ на: комментарий от drBatty

man один в один. Про то, что crtime появлется только при размере inode 256 байт там не написано.

дык это бэкпорт очевидно из 3.х в 2.6.

То есть в названии файла «2-6-27-rc3», а на самом деле он из 3.x?

Возмите https://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.1.tar.xz (это исходники ядра 15 октября 2008), там в файле ″fs/ext4/ialloc.c″ такие строки: 

799:    inode->i_mtime = inode->i_atime = inode->i_ctime = ei->i_crtime =
800:                                                   ext4_current_time(inode);

вот тот самый crtime. И в 3.1 строчка точно такая же, но немного подальше от начала файла.

Просто это crtime особо никому не нужен, поэтому про него никто и не знал, есть он или нет.

mky ★★★★★
()
Ответ на: комментарий от mky

man один в один. Про то, что crtime появлется только при размере inode 256 байт там не написано.

как я понимаю, crtime это и есть один из «расширенных атрибутов»(Extended attributes stored in large inodes).

То есть в названии файла «2-6-27-rc3», а на самом деле он из 3.x?

ну дык RH переносят фичи из новых ядер в старые. Иногда - криво. Например несколько лет назад перенесли дробные проценты в mke2fs -m, при чём так, что они вводились, но внутри обрезались до int. Потому 0.5% имело эффект 0%. Но в апстриме всё работало правильно. Т.ч. crtime тоже мог быть перенесён из 3.х, потому-как в 2.6 оно вроде не работало (в ваниле).

вот тот самый crtime. И в 3.1 строчка точно такая же, но немного подальше от начала файла.

это инициализация. Само поле там уже очень давно, может ещё в ext3 было, но вот читать его нельзя(было). Там вообще очень много полей reserved, обычное дело.

Просто это crtime особо никому не нужен, поэтому про него никто и не знал, есть он или нет.

я знал давно, но думал, что он не работает. Ну как сжатие и секьюрное удаление. (man chattr). Сейчас сырцы 3.8 гляну…

drBatty ★★
()
Ответ на: комментарий от drBatty

ну сейчас мы такой инод имеем: 

struct ext4_inode {
·   __le16· i_mode;··   /* File mode */
·   __le16· i_uid;· ·   /* Low 16 bits of Owner Uid */
·   __le32· i_size_lo;· /* Size in bytes */
·   __le32· i_atime;·   /* Access time */
·   __le32· i_ctime;·   /* Inode Change time */
·   __le32· i_mtime;·   /* Modification time */
·   __le32· i_dtime;·   /* Deletion Time */
·   __le16· i_gid;· ·   /* Low 16 bits of Group Id */
·   __le16· i_links_count;· /* Links count */
·   __le32· i_blocks_lo;·   /* Blocks count */
·   __le32· i_flags;·   /* File flags */
·   union {
·   ·   struct {
·   ·   ·   __le32  l_i_version;
·   ·   } linux1;
+----  3 строк: struct {-----------------------------------------------------------------------------------------------------------------------
+----  3 строк: struct {-----------------------------------------------------------------------------------------------------------------------
·   } osd1;··   ·   ·   /* OS dependent 1 */
·   __le32· i_block[EXT4_N_BLOCKS];/* Pointers to blocks */
·   __le32· i_generation;·  /* File version (for NFS) */
·   __le32· i_file_acl_lo;· /* File ACL */
·   __le32· i_size_high;
·   __le32· i_obso_faddr;·  /* Obsoleted fragment address */
·   union {
·   ·   struct {
·   ·   ·   __le16· l_i_blocks_high; /* were l_i_reserved1 */
·   ·   ·   __le16· l_i_file_acl_high;
·   ·   ·   __le16· l_i_uid_high;·  /* these 2 fields */
·   ·   ·   __le16· l_i_gid_high;·  /* were reserved2[0] */
·   ·   ·   __le16· l_i_checksum_lo;/* crc32c(uuid+inum+inode) LE */
·   ·   ·   __le16· l_i_reserved;
·   ·   } linux2;
+----  7 строк: struct {-----------------------------------------------------------------------------------------------------------------------
+----  5 строк: struct {-----------------------------------------------------------------------------------------------------------------------
·   } osd2;··   ·   ·   /* OS dependent 2 */
·   __le16· i_extra_isize;
·   __le16· i_checksum_hi;· /* crc32c(uuid+inum+inode) BE */
·   __le32  i_ctime_extra;  /* extra Change time      (nsec << 2 | epoch) */
·   __le32  i_mtime_extra;  /* extra Modification time(nsec << 2 | epoch) */
·   __le32  i_atime_extra;  /* extra Access time      (nsec << 2 | epoch) */
·   __le32  i_crtime;       /* File Creation time */
·   __le32  i_crtime_extra; /* extra FileCreationtime (nsec << 2 | epoch) */
·   __le32  i_version_hi;·  /* high 32 bits for 64-bit version */
};
первые ~128 байт это старый инод (где-то до i_extra_isize) это старые атрибуты (хотя на самом деле, ЕМНИП после i_block всё раньше было reserved), дальше - исключительно новые, которые не влезли в 128и битный инод

  • контрольная сумма инода
  • ctime hi (старшие 32 бита ctime)
  • mtime hi
  • atime hi
  • crtime
  • crtime hi
  • version hi
drBatty ★★
()
Ответ на: комментарий от drBatty

это инициализация.

Да, ициализация. И больше ядро в это поле по определению данные не заносит.

Само поле там уже очень давно, может ещё в ext3 было

В 2.6.27.1 хвост ″ext4_inode″ немного отличался, но crtime был: 

        } osd2;                         /* OS dependent 2 */
        __le16  i_extra_isize;
        __le16  i_pad1;
        __le32  i_ctime_extra;  /* extra Change time      (nsec << 2 | epoch) */
        __le32  i_mtime_extra;  /* extra Modification time(nsec << 2 | epoch) */
        __le32  i_atime_extra;  /* extra Access time      (nsec << 2 | epoch) */
        __le32  i_crtime;       /* File Creation time */
        __le32  i_crtime_extra; /* extra FileCreationtime (nsec << 2 | epoch) */
        __le32  i_version_hi;   /* high 32 bits for 64-bit version */
};
А вот в 2.6.22 всё заканчивалось на ″i_pad1″. Так что поле crtime появилось между 2.6.22 и 2.6.27. Выкачивать кучу ядер и смотреть когда именно оно появилось, ИМХО, смысла нет.

но вот читать его нельзя(было).

Компилировать ванильное ядро у меня желания нет. Но, вот, допустим вывод debugfs для ядра 2.6.28 http://kerneltrap.org/mailarchive/linux-ext4/2009/1/24/4803214/thread и в выводе видно crtime. Так что похоже, что поле crtime в inode давно содержит актуальную информацию, но знать её обычным пользователям не положено. Только root через debugfs.

mky ★★★★★
()
Ответ на: комментарий от mky

Да, ициализация. И больше ядро в это поле по определению данные не заносит.

заносит. 

/*
 * Post the struct inode info into an on-disk inode location in the
 * buffer-cache.  This gobbles the caller's reference to the
 * buffer_head in the inode location struct.
 *
 * The caller must have write access to iloc->bh.
 */
static int ext4_do_update_inode(handle_t *handle,
·   ·   ·   ·   struct inode *inode,
·   ·   ·   ·   struct ext4_iloc *iloc)
{

//<skip>
inode.c:4174:	EXT4_EINODE_SET_XTIME(i_crtime, ei, raw_inode);
оно всё скопом заносит, и crtime тоже. Т.е. в теории оно _может_ поменяться.

Компилировать ванильное ядро у меня желания нет. Но, вот, допустим вывод debugfs для ядра 2.6.28 http://kerneltrap.org/mailarchive/linux-ext4/2009/1/24/4803214/thread и в выводе видно crtime. Так что похоже, что поле crtime в inode давно содержит актуальную информацию, но знать её обычным пользователям не положено. Только root через debugfs.

у выходит - так. Значит ещё не доделали.

drBatty ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Перенос контейнеров с virtuozzo на openvz
Admin
squid закрыть зеркала ? →