Emacs может быть перемещен главным образом безопасно, даже если Вы не принимаете мер предосторожности при компиляции. Если пути hardcoded не работают, Emacs ищет каталоги около исполняемого файла.
Emacs пытается определить, где исполняемый файл, который вызвал его, расположен. Это хранит эту информацию в переменной invocation-directory
. Скажем, то, что это /path/to/bin/emacs
; Emacs ищет файлы данных, в которых он нуждается в трудно кодированных каталогах и отступает к каталогам в /path/to
.
Необходимо структурировать каталоги таким же образом как источник Emacs, более или менее, с каталогами верхнего уровня bin
, etc
, leim
, lib-src
, lisp
, site-lisp
. В частности, по крайней мере, с Emacs 23.2, каталогом lib-src
должен существовать (даже если это пусто).
Существует несколько каталогов, что Emacs не находит этот путь. Установите среду EMACSDATA=/path/to/etc
. Вы, возможно, должны установить INFOPATH
также.
Я не на 100% уверен, что это - то, что Вы ищете, но я полагаю, что можно сделать это использование команды hdparm
, конкретно с --fibmap
переключатель.
выборка
--fibmap
When used, this must be the only option given. It requires a
file path as a parameter, and will print out a list of the block
extents (sector ranges) occupied by that file on disk. Sector
numbers are given as absolute LBA numbers, referenced from sector
0 of the physical device rather than from the partition or
filesystem. This information can then be used for a variety of
purposes, such as examining the degree of fragmenation of larger
files, or determining appropriate sectors to deliberately corrupt
during fault-injection testing procedures.
This option uses the new FIEMAP (file extent map) ioctl() when
available, and falls back to the older FIBMAP (file block
map) ioctl() otherwise. Note that FIBMAP suffers from a 32-bit
block-number interface, and thus not work beyond 8TB or 16TB.
FIBMAP is also very slow, and does not deal well with
preallocated uncommitted extents in ext4/xfs filesystems, unless a
sync() is done before using this option.
Скажите, что у нас есть файл примера.
$ echo "this is a test file" > afile
Теперь, когда мы работаем hdparm
.
$ sudo hdparm --fibmap afile
afile:
filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
byte_offset begin_LBA end_LBA sectors
0 282439184 282439191 8
Другой хороший метод для обнаружения начала файла и конечных блоков filefrag
. Необходимо будет использовать соответствующие переключатели хотя, для получения желаемого вывода. Один позитивный аспект этого инструмента hdparm
тот любой пользователь, может выполнить его, таким образом, нет sudo
требуется. Необходимо будет использовать -b512
переключитесь так, чтобы выводы были отображены в 512-байтовых блоках. Также мы должны сказать filefrag
быть подробным.
$ filefrag -b512 -v afile
Filesystem type is: ef53
File size of afile is 20 (8 block of 512 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 7: 282439184.. 282439191: 8: eof
afile: 1 extent found
Третий метод для получения LBAs файла должен использовать debugfs
. Этот метод потребует небольшой математики, но я думал, что это важный показало, как можно преобразовать из значения степеней, о котором сообщают debugfs
к LBAs, для тех, которым могло бы быть любопытно.
Поэтому давайте запустимся с inode файла.
$ ls -i afile
6560281 afile
Примечание: Мы могли также использовать имя файла в debugfs
но для этой демонстрации я собираюсь использовать inode вместо этого.
Теперь давайте доберемся stat
информация через debugfs
о нашем inode.
$ sudo debugfs -R "stat <6560281>" /dev/mapper/fedora_greeneggs-home
debugfs 1.42.7 (21-Jan-2013)
Inode: 6560281 Type: regular Mode: 0664 Flags: 0x80000
Generation: 1999478298 Version: 0x00000000:00000001
User: 1000 Group: 1000 Size: 20
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x52be10c3:a640e994 -- Fri Dec 27 18:44:03 2013
atime: 0x52bff8a1:a9f08020 -- Sun Dec 29 05:25:37 2013
mtime: 0x52be0fe7:18a2f344 -- Fri Dec 27 18:40:23 2013
crtime: 0x52be0dd8:64394b00 -- Fri Dec 27 18:31:36 2013
Size of extra inode fields: 28
Extended attributes stored in inode body:
selinux = "unconfined_u:object_r:user_home_t:s0\000" (37)
EXTENTS:
(0):35304898
Важная информация находится в разделе степеней. Это блоки на самом деле файловой системы, которые используются этим inode. Мы просто должны преобразовать их в LBA. Мы можем сделать это посредством следующего уравнения.
Примечание: Предположение, что наша файловая система использует 4k размеры блока и что используемое оборудование использует 512-байтовые единицы, мы должны умножить exents на 8.
beginning LBA = (BEGIN EXTENT) * 8
ending LBA = (((ENDING EXTENT) + 1) * 8) - 1
Таким образом в нашем примере наше начало и конечная степень являются тем же, начиная с наших соответствий файла в единственной степени.
beginning LBA = 35304898 * 8 = 282439184
ending LBA = ((35304898 + 1) * 8) - 1 = 282439191
Таким образом, наши LBAs 282439184.. 282439191.
Так, для данного файла Вы хотите знать, какие числа дискового блока содержат запуск и конец того файла.
debugfs (8) взгляды, обещающие для ext2/3/4 FSes
статистика (1), ls-i, lsof (8) очень еще обеспечивает inode число, но не о дисковых блоках.
голова/хвост - bytes=1024 полезна для содержания файла, но не дисковых блоков.
dd (1) будет тем, чего Вы хотите осмотреть содержание блока - остерегаться различия между исканием = и пропуском = параметры, и избежать =/dev/..., если Вы действительно не хотите, чтобы выходной файл был устройством.
hdparm --fibmap
перечислит блоки, которые занимает файл. Обратите внимание, что они не могут быть непрерывными, таким образом, "запускаются и заканчиваются", не имеет смысла.
--fibmap
. Также необходимо указать имя файла w/это. Пример: hdparm --fibmap afile
.
– slm♦
28.12.2013, 01:35
hdparm
был на целом уровне диска, никогда не использовал его для файлов прежде.
– slm♦
28.12.2013, 03:43
(Обратите внимание, что hdparm --fibmap
относится ко всему диску, а не к разделу или любому другому блочному устройству, хранящему ФС. Для этого также требуется root.)
filefrag -e
работает хорошо, и использует общий и эффективный FIEMAP
ioctl, поэтому он должен работать практически на любой файловой системе (включая часто странную BTRFS, даже для BTRFS-сжатых файлов). Он будет возвращаться к FIBMAP для файловых систем / ядер без поддержки FIEMAP.
$ filefrag xpsp3.vdi # some old sparse disk image I had lying around
xpsp3.vdi: 110 extents found
$ filefrag -e xpsp3.vdi
Filesystem type is: 58465342
File size of xpsp3.vdi is 5368730112 (1310726 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 5: 1322629241..1322629246: 6:
1: 13.. 13: 1322620799..1322620799: 1: 1322629247:
2: 15.. 47: 1323459271..1323459303: 33: 1322620800:
...
160: 899498.. 915839: 1325792977..1325809318: 16342: 1325725438:
161: 1307294.. 1307391: 1323938199..1323938296: 98: 1325809319: last
xpsp3.vdi: 110 extents found
Если вы используете xfs, то xfs_bmap
имеет более приятный вывод: Он показывает, где есть дыры, в то время как filefrag
просто показывает следующий экстент, начинающийся с более позднего сектора. Он использует блоки 512B, а не тот размер блоков, который на самом деле имеет файловая система. (обычно 4k в Linux). Он показывает, в какой группе распределения находится каждый экстент, и как он выровнен по границам полос RAID.
$ xfs_bmap -vvpl xpsp3.vdi # the extra -v prints a key to the flags
xpsp3.vdi:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..47]: 10581033928..10581033975 13 (83912..83959) 48 01111
1: [48..103]: hole 56
2: [104..111]: 10580966392..10580966399 13 (16376..16383) 8 01010
3: [112..119]: hole 8
...
322: [10458352..10459135]: 10591505592..10591506375 13 (10555576..10556359) 784 01111
323: [10459136..10485807]: hole 26672
FLAG Values: # this part is only here with -vv
010000 Unwritten preallocated extent
001000 Doesn't begin on stripe unit
000100 Doesn't end on stripe unit
000010 Doesn't begin on stripe width
000001 Doesn't end on stripe width
-l
является избыточным при использовании -v
, но по какой-то причине я всегда ввожу -vpl
. -pl
- более компактный вывод.
filefrag
, и xfs_bmap
показывают предварительно распределенные экстенты. $ fallocate --length $((1024*1024*8)) prealloced_file
$ filefrag -e prealloced_file
Filesystem type is: 58465342
File size of prealloced_file is 8388608 (2048 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 2047: 1325371648..1325373695: 2048: last,unwritten,eof
prealloced_file: 1 extent found
$ xfs_bmap -vvpl prealloced_file
prealloced_file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..16383]: 10602973184..10602989567 13 (22023168..22039551) 16384 10010
FLAG Values:
010000 Unwritten preallocated extent
001000 Doesn't begin on stripe unit
000100 Doesn't end on stripe unit
000010 Doesn't begin on stripe width
000001 Doesn't end on stripe width
$ dd if=/dev/zero of=prealloced_file conv=notrunc bs=4k count=10 seek=10000
40960 bytes (41 kB) copied, 0.000335111 s, 122 MB/s
$ xfs_bmap -vpl prealloced_file
prealloced_file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..16383]: 10602973184..10602989567 13 (22023168..22039551) 16384 10010
1: [16384..79999]: hole 63616
2: [80000..80895]: 10603013120..10603014015 13 (22063104..22063999) 896 00111
# oops, wrote past EOF and extended the file, instead of in the middle of the preallocated extent
$ dd if=/dev/zero of=prealloced_file conv=notrunc bs=4k count=10 seek=100
40960 bytes (41 kB) copied, 0.000212986 s, 192 MB/s
$ xfs_bmap -vpl prealloced_file
prealloced_file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..16383]: 10602973184..10602989567 13 (22023168..22039551) 16384 10010
1: [16384..79999]: hole 63616
2: [80000..80895]: 10603013120..10603014015 13 (22063104..22063999) 896 00111
# If you check *right away*, XFS's delayed allocation hasn't happened yet.
# FIEMAP on xfs only reflects allocations, which lag behind completed writes. fsync first if you need it, IIRC.
$ xfs_bmap -vpl prealloced_file
prealloced_file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..799]: 10602973184..10602973983 13 (22023168..22023967) 800 10111
1: [800..879]: 10602973984..10602974063 13 (22023968..22024047) 80 01111
2: [880..16383]: 10602974064..10602989567 13 (22024048..22039551) 15504 11010
3: [16384..79999]: hole 63616
4: [80000..80895]: 10603013120..10603014015 13 (22063104..22063999) 896 00111
$ filefrag -e prealloced_file
Filesystem type is: 58465342
File size of prealloced_file is 41000960 (10010 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 99: 1325371648..1325371747: 100: unwritten
1: 100.. 109: 1325371748..1325371757: 10:
2: 110.. 2047: 1325371758..1325373695: 1938: unwritten
3: 10000.. 10111: 1325376640..1325376751: 112: 1325373696: last,eof
prealloced_file: 2 extents found
hdparm --fibmap
полезен только если вам нужен номер сектора относительно всего жесткого диска, а не внутри раздела, на котором находится файловая система. Он не работает поверх программного RAID-массива (или предположительно чего-либо еще между файловой системой и жестким диском). Он также требует наличия корня. Несмотря на название опции, она фактически использует FIEMAP
, когда это доступно (более новый extent-map ioctl, а не старый медленный block-map ioctl).
# hdparm --fibmap ..../xpsp3.vdi
Unable to determine start offset LBA for device, aborting.
filefrag
. – slm♦ 29.12.2013, 12:07debugfs
. – slm♦ 29.12.2013, 19:43filefrag
с доступным blocksizes 1 024 и 2048..debugfs
с большим файлом степени: 0 - 12187.. я буду не торопиться и понимать.. это - большая справка, спасибо... – precise 29.12.2013, 20:58