Tag Info

New answers tagged

1

It looks like Petalinux uses /etc/rcS.d for its init scripts, the following is a step by step that should allow you to resolve this issue: http://www.xilinx.com/support/answers/55998.htm Please let us know if you have any further issues.


1

That rootfs entry is the real root filesystem. It has no device; it is a tmpfs that is automatically mounted by the kernel very early during initialization. Later during the boot process, your disk root filesystem is mounted over top of the rootfs, hiding it from view.


1

I think you should be looking into /proc/mounts: $ cat /proc/mounts That file has exact device, filesystem and other mount options used to mount different filesystems on your OS. The format is same as of /etc/fstab.


0

Following the documentation, the encryption cipher used is configuration dependent and as I understand could be any (symmetric) cipher the underlying encryption library supports: Cipher Which encryption algorithm to use. The list is generated automatically based on what supported algorithms EncFS found in the encryption libraries. When using a ...


2

rootfs mounted on / is an in-memory filesystem which typically only contains the tools needed to mount the “real” root filesystem and is emptied after this is done. The initial content of the rootfs are loaded from an initramfs image stored inside or next to the kernel binary and loaded by the bootloader. The root filesystem on flash is ubi0:root. This is a ...


3

There is no difference betweem tmpfs and shm. tmpfs is the new name for shm. shm stands for SHaredMemory. See: Linux tmpfs. The main reason tmpfs is even used today is this comment in my /etc/fstab on my gentoo box. BTW Chromium won't build with the line missing: # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for # POSIX shared memory ...


0

I had the problem this weekend: 1000000 text files of 5-20 kb. These text files are never changed, so the best solution for me was mksquashfs: Today disk I/O is much more expensive than uncompressing 1 MB extra. It is, however, not a general solution: If you need to change or add files this will not work (In which case I would recommend Btrfs).


0

I came up with a systemtap script which is close to what I wanted to do, but it does not track writes. The code is on a gist: https://gist.github.com/Martiusweb/10633360


0

About a month ago, I did exactly what you are asking via PartedMagic (LiveCD) in separate steps: Select entire extended partition border, shrink to the right (or calculate offset/size) and apply/commit. Now reboot (1st reboot). If I recall, the space was still unallocated except it was now outside of the extended partition. i.e. a 2nd primary. Take note, ...


0

On a similar vein to @maxschlepzig's answer, you can parse the output of filefrag to sort files in the order that their first fragments appear on disk: find . -maxdepth 1 -type f | xargs -d'\n' filefrag -v | sed -n ' /^ 0: 0../ { s/^.\{28\}\([0-9][0-9]*\).*/\1/ h } / found$/ { s/:[^:]*$// H g ...


3

tar handles hardlinks on its own. cd "$srcdir" ; tar --hard-dereference -cf - ./* | tar -C"${tgtdir}" -vxf - That way you only have the two tar processes and you don't need to keep invoking cp over and over again.


2

No it will not move the entire extended partition nor make the space contigious. Although in theory the extended partition could just be recreated with the same logical partitions, that would mean that the entries stay in place (with some zero size first, logical partition), or you would have to rearange the Extended partition information. Both that would ...


3

Assuming that entries returned by readdir are not sorted by inode number reading files in inode order reduces the number of seek operations the content of most files are in the initial 8k allocation (an ext4 optimization) which also should yield less seek operations you can try to speed up copying via copying files in inode order. That means using ...


0

Earlier computers (and some modern embedded systems) do not have a filesystem. My Apple ][ (and the school's Commodore PET) had the OS in ROM and was ready to roll about 2 seconds after a cold boot. Want to load software? Either type the source in manually, or type LOAD, press enter, and then PLAY on the tape machine. Then we got a disk drive - and there was ...


0

If you want the Linux OS to function then it has to have a file system. But there is no requirement that the file system be on a hard disk (or SSD etc). In fact there is not even a requirement that Linux be on the device at all. You can use the BOOTP protocol to load the OS over the network. You do need quite a bit of RAM though for this to be ...


2

Let's have a brief look onto the function: int blkid_superblocks_get_name(size_t idx, const char **name, int *usage) { if (idx < ARRAY_SIZE(idinfos)) { if (name) *name = idinfos[idx]->name; if (usage) *usage = idinfos[idx]->usage; return 0; } return -1; } name is a pointer to a char * ...


0

File systems are a means for operating systems to organize persistently stored data. Specifically, they enable the OS to store and retrieve data efficiently. When you say you have booted from a flash drive, that means that this flash drive certainly has a file system. The fact that the kernel has loaded a driver means that it must have had a way to find ...


5

Actually, technically speaking you don't need a file system. The default behaviour is to have a file system from which to boot. (e.g. /sbin/init is launched from there). However, if you like you can look at what happens in do_basic_setup() in linux-source/init/main.c. By the time that routine gets called, the kernel and CPU0 are ready for real work. You can ...


7

I wrote an answer to to a related question that details how the concept of a file is core to the way Unix works, and since you can't have a file without some kind of filesystem, it means that you definitely need one. However it is possible to survive without a filesystem that exists on any persistent storage media. Your initramfs image can be compiled into ...


1

A filesystem provides more than just a place to store files. It is where the executables (programs), libraries and configuration files for your system live. At a minimum the linux kernel requires a filesystem to allow it to find/execute the "init" process that is responsible for ensuring that other processes are started as appropriate for your system. ...


15

If you need Linux, you need a filesystem. (I mean Linux the operating system here, rather than Linux the OS kernel. I'll get to that narrower interpretation below.) Your observation about device drivers loading at boot before the filesystem exists is a red herring. You can load a driver without having a filesystem. What you can't do is fd = ...


-3

No, linux does not need to have a filesystem in a very strict sense. In your case you have a different issue. "No filesystem could mount root, tried: jffs2" "MTD: MTD device with name "jffs2" not found." My guess is some part of the load process either is not finding a/the place to mount or doesn't have the ability to mount that filesystem.


-1

Now that I look again, I realized you said this was a usb key ( flash drive ) not a hard drive. Flash memory can only be erased in large blocks, and individual sectors can not be written without erasing them ( and the whole block they are in ) first. Since software expects to be able to write wherever it wants on the disk at any time, the disk has ...


-1

This happens due to the optimization of writing Sparse files in filesystem. When you do dd if=/dev/zero to raw device, the zero blocks are actually written to disk. However when you write them to a file, the filesystem ignores writing the data and saves just the metadata. This results in very few blocks being written to disk. The file can be seen as a big ...


0

mkfs.ext4 -T largefile ... and never mind about defrag... Use LVM, not a filesystem.


3

^@ is a representation of the null byte. You can get a better picture from xxd or od. If the contents of the file has been lost, the fix would be to restore it from the version control system or backups.


0

Try using hdparm instead to benchmark a drives performance with and without using any caching: $ sudo hdparm -tT /dev/sda1 /dev/sda1: Timing cached reads: 6314 MB in 2.00 seconds = 3157.61 MB/sec Timing buffered disk reads: 244 MB in 3.04 seconds = 80.26 MB/sec


0

Your measurement results can be explained with the kernel architecture. Using filesystem access will unlease the full potential of the kernel with all buffers and optimizations that it can do. Especially the buffers will speed up your benchmark (b/c the kernel is 100% a_A_syncronous). dd on a device file does not use any/much of this.


1

But what I'd like to know is whether or not all of my files on it are fine. Ext3 has no functionality for this, but questions like that come up in IT-security as well. The solution there is to create a list of hash-sums (i.e. practically unforgeable checksums) over the files and its meta-data and compare these stored sums with the actual sums at times ...


0

I couldn't add a comment. So I am putting it here. Apart from the filesystem test, may be you can also you the Disk Utility to run SMART test on the disk and verify the health of the disk.


2

Is there some way, either general or specific, that I can verify that none of the files on my filesystem were damaged? Without copies of the files to refer to, I think this is impossible. Have you looked in /lost+found? If anything was corrupted into pieces, those pieces will be left there by fsck. I have seen this happen before too, and as far as I ...


15

You can use the command archivemount to mount archives such as .tar.gz. $ ls files.tgz mnt/ $ archivemount files.tgz mnt $ ls mnt file1 file2 [... Perform desired read/write operations on the archive via mnt/ ...] $ umount mnt [... Any changes are saved to the archive ...] See the man page for archivemount for more info. It's often times not ...


6

You're either talking about a FUSE filesystem (filesystem in userspace - Linus calls them toys) or a custom compiled kernel OR squashfs. Squash is not exactly as you describe - you cannot simply mount a tarball for instance - not with the kernel supported VFS, anyway - but you can certainly mksquash any number of files or directories and mount the resulting ...


1

This is reposted from here at the asker's behest: du --inodes -S | sort -rh | sed -n \ '1,50{/^.\{71\}/s/^\(.\{30\}\).*\(.\{37\}\)$/\1...\2/;p}' And if you want to stay in the same filesystem you do: du --inodes -xS Here's some example output: 15K /usr/share/man/man3 4.0K /usr/lib 3.6K /usr/bin 2.4K /usr/share/man/man1 1.9K ...


1

As said with another related answer, you can't trust dumpe2fs in a mounted partition. It's very likely that it's erroneous or outdated. Unmount the partition and try again.


0

I've run into this problem for years on live CD/DVD/USB distros like Debian, Ubuntu, Mint, maybe even Fedora if I recall. Memory used by overlayfs (the currently used fstype for live Mint/Ubuntu) and tmpfs are hidden in free 's cached memory (and /proc/meminfo's Inactive entries), along with temporary disk read caches, so it's unclear how much memory is ...


1

Yes blocks are better as they are physical disk usage but you need to obtain them in a different manner Use the os.stat field st_blocks * 512. https://docs.python.org/2/library/os.html#os.stat os.stat(path) Perform the equivalent of a stat() system call on the given path. (This function follows symlinks; to stat a symlink use lstat().) On ...


0

And don't forget sparse files: $ dd if=/dev/null of=MEAN_FILE bs=1024k seek=1024k 0+0 Datensätze ein 0+0 Datensätze aus 0 Bytes (0 B) kopiert, 1,0298e-05 s, 0,0 kB/s $ ls -lh MEAN_FILE -rw-r--r-- 1 yeti yeti 1,0T Apr 3 09:44 MEAN_FILE $ du MEAN_FILE 0 MEAN_FILE


0

Counting exactly what a file really occupy on the disk is not trivial, as a thorough answer is more complex than just rounded up the file size to the next disk block. What about: hard link? exotic filesystem inner way of allocating disk space (half block allocation)? compressed filesystem? fancy feature such as "de-duplication"? If you add all this up, ...


1

One likely reason for running out of inodes is that a large number of files has accumulated in a particular directory for whatever reason. You could check the usual suspects, eg /tmp, /var/tmp, /var/log etc. If you don't find anything, here is a command that I have cobbled together to list the top 50 directories in the filesystem containing the most ...


1

Looking at the comments others have helped you diagnose you're out of inodes. If you need to make a few available so you can get some basic access back to your system then you could delete the following files on a CentOS 5 install, assuming you can live without them. Example $ sudo rm -fr /var/log/*.[1-9]?(.gz) This will remove any of the previously ...


0

If you have e2fsprogs 1.42.9, then you can use e2image to create the partition image without the free space in the first place, so you can skip the zeroing step.


1

The resize_inode feature creates a hidden inode ( number 7, you can view it in debugfs with stat <7> ) to reserve those blocks so that the GDT can be grown. By default it reserves enough space to grow the filesystem to 1024 times its original size. You can disable the feature or adjust the size using options to mke2fs at format time. What does ...


-2

You can use sfill. It's a better solution for thin volumes.


2

The crux of the answer given by several others above is that the every file name is a hard link to a file. There is no real original, just possibly a first one. Think of a directory as a table that lists file names and inode-numbers. Every hard link, including the first one, is an entry in a directory which assigns a "file name" to the inode number, so ...


8

I think this question is (quite reasonably) misguided as to what a hard link really is. I think however the most correct direct answer is 'They both are'. Unix file systems normally store actual file contents and data in i-nodes, these do not have a path whatsoever, paths then have a many to one relationship to these i-nodes. Take as an analogy a person who ...


0

Following my comment I have just remembered this great command : iotop iotop watches I/O usage information output by the Linux kernel (requires 2.6.20 or later) and displays a table of current I/O usage by processes or threads on the system. However it is usually not installed so since your server seems to be in production, you may want to have a look ...


5

As of GNU coreutils 8.21 (changelog), df has a --output option. Using sed to trim the header: df -h --output=size,used,avail,pcent | sed 1d


2

findmnt -Do SIZE,USED,AVAIL,USE% Here's my output: SIZE USED AVAIL USE% 11.8G 0 11.8G 0% 11.8G 63.1M 11.7G 1% 11.8G 920K 11.8G 0% 11.8G 0 11.8G 0% 12G 8.9G 2.7G 74% 11.8G 410.6M 11.4G 3% 3G 584.4M 2.4G 19% 3G 584.4M 2.4G 19% 2.4G 4K 2.4G 0% 0 0 0 - So if you're not already using findmnt ...


2

Assuming filesystems and mount points don't contain blank characters, try: df -hP | awk 'NR>1 { $1=$6="" ; print }' | column -t df -hP lists the filesystem statistics without linebreaks for long filesystem names. awk 'NR>1 { ... }' restricts the given action to 2nd and following lines to skip df's header line... The awk-action { $1=$6="" ; print } ...



Top 50 recent answers are included