Tag Info

New answers tagged

0

I pretty much had the same issue, trying to mount gave: $sudo mount /dev/sda2 ./oldfs/ mount: wrong fs type, bad option, bad superblock on /dev/sda2, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so I tried the above mentioned re-writing of the part-table, without success. ...


1

Ceph's recommendation for the choice of filesystem is between btrfs and XFS. ext4 is not recommended. From that page: We currently recommend XFS for production deployments. We recommend btrfs for testing, development, and any non-critical deployments. We believe that btrfs has the correct feature set and roadmap to serve Ceph in the long-term, but XFS ...


0

Not an answer to the question, but I got curious so I imagine other people will. Since I had a liveCD booted already, and had a hard drive I could mess with without worrying about typos damaging anything, I went ahead and tested. I made partitions with all of the FSes that Ubuntu 14.10 ships an mkfs for, on 100MiB partitions. (except minix, which only ...


18

The short answer: Not all space on the block device becomes available space for your data: some of the raw space is needed for file-system internals, the behind the scenes bookkeeping. That bookkeeping includes the super block, block group descriptors, block and inode bitmaps, and the inode table. In addition copies of the super block for backup/recovery ...


31

Try this: mkfs.ext4 -N 104 -m0 -O ^has_journal,^resize_inode /dev/purgatory/test1 I thinks this does let you understand "what is going on". -N 104 (set the number of iNodes you filesystem should have) every iNode "costs" usable space (128 Byte) -m 0 (no reserved blocks) -O ^has_journal,^resize_inode (deactivate the features has_journal and ...


3

Lack of partitions is a common cause for needing recovery in the first place. A partition table is the most common / standard way to declare that the disk is in use (and thanks to various partition types, it usually also declares what exactly each partition is used for). An unpartitioned disk looks like an unused disk to many programs; installers select ...


2

This was true once - once upon a time drives were smaller (and slower), as were tapes. If you have a large raid group, and suffer a (compound) fault - all data on that raid group must be recovered. As sizes increase, so too do the numbers of tapes required. So a large filesystem, where you're doing a full restore might mean recovering everything and ...


5

To illustrate the question in a simple and efficient manner, consider two scenarios: You install your favourite linux distribution on entire disk i.e. without any partitions: Suppose your system is crashed because operating system is unable to access some sectors and unable to boot. You lost some chunk of data due to bad sectors and because of that you ...


1

Apparently it was a bug in the kernel. It was fixed in https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/scsi/storvsc_drv.c?id=e86fb5e8ab95f10ec5f2e9430119d5d35020c951


0

I was about to answer with the issue being you're trying to remove a read-only file inside of a directory you have write permissions on. Try resetting the permissions on the folder recursively with chmod -R 700 /home/emma/cd It'll be from when you copied preserving permissions inside of MC. Hope this helps a little, I would have commented but I'm new here ...


0

I've found the answer myself here. Because cd/Drivers is read-only, only root can delete from it.


1

Given that the filesystem was exported via NFS, there’s a fair chance that the discrepancy was due to deleted files... If files are deleted while open on NFS clients, lsof on the server won’t see them because there is no /proc/.../fd entry corresponding to them; but they will still occupy disk space as seen by df. Diagnosing this requires running lsof with ...


0

Try doing: sudo rm path/to/file if you cant do that then try sudo rm -r path/to/file


0

As you're working on a ext4 filesystem it could be possible that those files have the inmutable attribute enabled. You should check it with lsattr. Ex: antonio@PC1:~/antonio/borrar$ lsattr undelete -u--i--------e-- undelete


0

fuser -k -M -m /mnt/work should heel. Warning! it just literally kills processes accessing /mnt/work. Include -TERM to request termination. The culprit is deleted files that are held open, which du can't see but df could. For e.g. $ df -h . Filesystem Size Used Avail Use% Mounted on /dev/sda6 209M 66M 128M 35% /boot $ sudo du -sh . 64M ...


1

I believe some additional information is necessary for a certain answer, but I would suspect the issue is simply permissions related. I'm guessing either you accidentally copied symlinks over instead of the real files, or you're trying to delete the entire directory but haven't reset permissions on all the files within. First things first, when you stat ...



Top 50 recent answers are included