Search Results

Search found 760 results on 31 pages for 'ext4'.

Page 1/31 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

• CentOS 5.5 ext4 conversion problem - ext4 partition is recognized as ext3

  - by FractalizeR

  Hello. I had 5.4 machine. Upgraded to 5.5 today via yum upgrade. All went fine. Rebooted. Wanted to convert root partition to ext4 (I have three partitions: /boot, / and swap). All of them on software RAID 1 (root is /dev/md2). I did the following for converting yum install e4fsprogs tune2fs -O extents,uninit_bg,dir_index /dev/md2 nano /etc/fstab # I indicated here that my /dev/md2 is of ext4 uname -a mkinitrd -f /boot/initrd-2.6.18-194.3.1.el5.img 2.6.18-194.3.1.el5 Rebooted. I expected fsck to start automatically as said on some site. But it did not. Threw some error (don't remember exactly which). Ok, I booted linux rescue and executed fsck: fsck -t ext4 -fy /dev/md2 Partition went fine. But still when I boot main system, it says in log: "ext3-fs:" then something about not being able to mount ext3 partition due to unknown extended attributed (200). I booted linux rescue again. It loads fine and correctly determines all my machine partitions both ext3 (boot) and ext4 (/) under /mnt/sysimage just fine. I retried mkinitrd thing again watching it's output and ensured ext4 module is included into the system. I also edited menu.lst grub file to include rootfstype=ext4 kernel parameter. Bad luck. I still have message from ext3-fs about not being able to mount filesystem because of attributes and kernel panic immediately after. I checked /etc/fstab - it's fine and saying that root is of ext4. What did I do wrong? This machine is empty so I can just reformat it with 5.5 and recreate partitions to be originally ext4. But... I just want to know what did I do wrong.

  Read the article

• ext4 jbd2 journaling active even on empty filesystem

  - by Paul

  I have been having several issues with my ext4 filesystems that seem to be due to jbd2 journaling. I made a related post here and am rephrasing it with the hope that someone may be able to help. For a minimal example, I start with an empty 8gb USB stick and use gparted to create one ext4 partition. The command used by gparted when creating the ext4 file system is: mkfs.ext4 -j -O extent -L DataTraveler8gb /dev/sde1 I check the filesystem with gparted: e2fsck -f -y -v /dev/sde1 and I mount it: sudo mount /dev/sde1 /media/test The disk is empty, but the journaling is very active on this disk (/dev/sde1). The other disks are ext4 SSDs formatted similarly. A snapshot of iotop: % sudo iotop -oPa Total DISK READ: 0.00 B/s | Total DISK WRITE: 2027.21 K/s PID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND 262 be/3 root 0.00 B 56.00 K 0.00 % 0.18 % [jbd2/sda1-8] 29069 be/3 root 0.00 B 0.00 B 0.00 % 0.16 % [jbd2/sde1-8] 891 be/3 root 0.00 B 4.00 K 0.00 % 0.03 % [jbd2/sdc1-8] What is jbd2 doing with /dev/sde1? If I follow the same steps with a larger 2Tb disk, iotop indicates this empty disk is constantly being written to by jbd2 at the rate of Mb/s as soon as I mount it. On the other disks, which have the OS and /home, I have tried to find if any files are being modified by processes to cause this behavior but couldn't find any. I also moved many of the disk intensive process to use a tmpfs. And used noatime. I have another non-SSD hard disk on this machine, /dev/sdb, that is also ext4 but was not formatted by gparted (given to me by a coworker). It does not appear in iotop. So I am assuming there an issue with gparted. Any suggestions are appreciated. Also any tips on how to modify existing partitions to fix the issue without having to start from scratch would be great. There are some posts related to jbd2 but they didn't help (eg. here).

  Read the article

• ext4 hogs lot of unkown space compared to ext3

  - by rejith

  Ext4 FS has claimed 3% of partition space. Where has this gone and can I get it reclaimed? I have tried disabling Journals for the ext4 partition. Even this is not helping. Any other tricks I can try to get the space reclaimed other than reverting back to ext3? $ lsb_release -cr Release: 12.04 Codename: precise df -hP |grep media /dev/sda3 21G 430M 20G 3% /media/MAIL /dev/sda2 148G 188M 148G 1% /media/DATA => if I move this to ext4 its claiming 2.4G /dev/sda3 on /media/MAIL type ext4 (rw,nosuid,nodev,uhelper=udisks) /dev/sda2 on /media/DATA type ext3 (rw,nosuid,nodev,uhelper=udisks) $ sudo tune2fs -l /dev/sda3 |grep 'Reserved block count' Reserved block count: 0 $ sudo tune2fs -l /dev/sda2 |grep 'Reserved block count' Reserved block count: 0 NO hidden files or directories $ sudo du -ah *;pwd 16K lost+found /media/MAIL

  Read the article

• Repair ext4 filesystem on USB drive

  - by phineas

  Yet another filesystem question. I wanted to use a USB drive that I hadn't mounted for a month or so and was surprised by the fact Ubuntu was unable to mount it. I looked it up in the disk utility and it said it discovered a device with 17 MB instead of 2 GB. The hardware looks intact, I hope for the best for repairing the ext4 filesystem. I followed the instructions from HOWTO: Repair a broken Ext4 Superblock in Ubuntu, but I wasn't successful. # fsck.ext4 -v /dev/sdb e2fsck 1.42.5 (29-Jul-2012) ext2fs_open2: Bad magic number in super-block fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 Filesystem blocks are invalid, however when I run the recommended solution to try the alternate superblock, I get the following output: # e2fsck -b 8193 /dev/sdb e2fsck 1.42.5 (29-Jul-2012) e2fsck: Invalid argument while trying to open /dev/sdb plus the same error message as in the last paragraph above. Any ideas how to recover the drive? Thank you very much! Edit: testdisk won't help. I'm still stunned why the tools only discover 17 MB.

  Read the article

• mount ext4 formated external drive->the drives green light won't stop flashing

  - by Gohlool

  I've installed kubuntu (after 10 years I am trying to play with linux) and manged to attach a external 1TB HDD drive over USB! The drive was formatted with NTFS and everything was working OK. I also changed the /etc/fstab here is my ntfs mount setting: /dev/sdb1 /media/samsung nts-3g auto,user,uid=1000,gid=1000,fmask=000,utf-8 0, 0 Now, I've reparationed the drive and formated it with ext4 filesystem! change my fstb like: /dev/sdb1 /media/samsung ext4 defaults,noatime 0, 0 now, when I plug my dive/or call sudo mount -a, my external drive's green light starts to flash and won't stop, but mount works .... What is the Problem? is this because of ext4? because with NTFS this won't happen! btw. after changing the owner of the /media/samsung and setting permissions 777, I can also access my drive like creating new folder atc. (although is's flashing constantly)! What is my mistake? btw. can you please let me know how to set the owner and the permissions for my /media/samsung directory in fstab for ext4 like I did it for NTFS? Thanks in advance

  Read the article

• High CPU load for 1:30 minutes when mounting ext4-raid partition

  - by sirion

  I have a raid 5 (software) with 5x2TB drives. I encrypted the raid with cryptsetup and put an ext4-partition on top. In the beginning opening and mounting the raid took less than 10 seconds, now (for a few weeks) mounting alone takes 1:30 minutes and the cpu stays around 93% the whole time: The output of "time sudo mount /dev/mapper/8000 /media/8000" is: real 1m31.952s user 0m0.008s sys 1m25.229s At the same time only one line is added to /var/log/syslog: kernel: [ 2240.921381] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null) My Ubuntu-version is "12.04.1 LTS" and no updates are pending. I checked the partition with fsck, but it says that all is ok. The "cryptsetup luksOpen" command only takes a few seconds. I also tried changing the raid-bitmap (as it was suggested in some forum) but it did not change the behaviour. sudo mdadm --grow /dev/md0 -b internal and sudo mdadm --grow /dev/md0 -b none I had the idea that it might be the hardware being slow, but a read test with "sudo hdparm -t /dev/md0" spit out values between 62 and 159 MB/sec: Timing buffered disk reads: 382 MB in 3.00 seconds = 127.14 MB/sec Timing buffered disk reads: 482 MB in 3.02 seconds = 159.62 MB/sec Timing buffered disk reads: 190 MB in 3.03 seconds = 62.65 MB/sec Timing buffered disk reads: 474 MB in 3.02 seconds = 157.12 MB/sec Although I think it is strange that the read rate jumps by more than 100% - could that mean something? The speed test when reading from the mapped (decrypted) device shows similar behavior, although it is of course much slower. "sudo hdparm -t /dev/mapper/8000": Timing buffered disk reads: 56 MB in 3.02 seconds = 18.54 MB/sec Timing buffered disk reads: 122 MB in 3.09 seconds = 39.43 MB/sec Timing buffered disk reads: 134 MB in 3.02 seconds = 44.35 MB/sec The output of a verbose mount "mount -vvv /dev/mapper/8000 /media/8000" does not help much: mount: fstab path: "/etc/fstab" mount: mtab path: "/etc/mtab" mount: lock path: "/etc/mtab~" mount: temp path: "/etc/mtab.tmp" mount: UID: 0 mount: eUID: 0 mount: spec: "/dev/mapper/8000" mount: node: "/media/8000" mount: types: "(null)" mount: opts: "(null)" mount: you didn't specify a filesystem type for /dev/mapper/8000 I will try type ext4 mount: mount(2) syscall: source: "/dev/mapper/8000", target: "/media/8000", filesystemtype: "ext4", mountflags: -1058209792, data: (null) Any idea where I could find additional information on why mounting takes so long, or what additional tests I could run?

  Read the article

• western digital caviar black. EXT4-fs error [migrated]

  - by azat

  Recently I update my HDD on desktop machine, and bought WD Caviar Black. But after I format & copy information to it (using dd), and fix partitions size: I have next errors in kern.log: Aug 27 16:04:35 home-spb kernel: [148265.326264] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 9054, 32254 clusters in bitmap, 32258 in gd Aug 27 16:07:11 home-spb kernel: [148421.493483] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 9045, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:17 home-spb kernel: [148546.481693] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 10299, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:17 home-spb kernel: [148546.487147] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.258711] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4345, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.277591] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.278202] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4344, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.284760] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.291983] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 9051, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.297495] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.297916] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 9050, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.297940] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.303213] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4425, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.312127] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.312487] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4424, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.317858] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.322231] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4336, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.326250] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.326599] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4335, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.332397] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.341957] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 5764, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.350709] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.351127] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 5763, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.355916] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:43 home-spb kernel: [148572.401055] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 10063, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:43 home-spb kernel: [148572.404357] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:43 home-spb kernel: [148572.414699] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 10073, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:43 home-spb kernel: [148572.420411] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:43 home-spb kernel: [148572.493933] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 9059, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:43 home-spb kernel: [148572.493956] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. One time, machine rebooted (not manually), when I turn it on, it runs fsck on /dev/sdc2 and fix some errors and some files are missing on /dev/sdc2 I'v check /dev/sdc2 for badblocks, it doesn't have it ( using e2fsck -c /dev/sdc2 ) Here is the output of fsck http://pastebin.com/D5LmLVBY What else I can do to understand what's wrong here? BTW for /dev/sdc1 no message like that, in kern.log Linux version: 3.3.0 Distributive: Debian wheezy

  Read the article

• western digital caviar black. EXT4-fs error

  - by azat

  Recently I update my HDD on desktop machine, and bought WD Caviar Black. But after I format & copy information to it (using dd), and fix partitions size: I have next errors in kern.log: Aug 27 16:04:35 home-spb kernel: [148265.326264] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 9054, 32254 clusters in bitmap, 32258 in gd Aug 27 16:07:11 home-spb kernel: [148421.493483] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 9045, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:17 home-spb kernel: [148546.481693] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 10299, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:17 home-spb kernel: [148546.487147] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.258711] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4345, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.277591] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.278202] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4344, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.284760] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.291983] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 9051, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.297495] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.297916] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 9050, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.297940] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.303213] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4425, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.312127] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.312487] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4424, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.317858] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.322231] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4336, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.326250] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.326599] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 4335, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.332397] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.341957] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 5764, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.350709] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:42 home-spb kernel: [148572.351127] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 5763, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:42 home-spb kernel: [148572.355916] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:43 home-spb kernel: [148572.401055] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 10063, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:43 home-spb kernel: [148572.404357] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:43 home-spb kernel: [148572.414699] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 10073, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:43 home-spb kernel: [148572.420411] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Aug 27 16:09:43 home-spb kernel: [148572.493933] EXT4-fs error (device sdc2): ext4_mb_generate_buddy:739: group 9059, 32254 clusters in bitmap, 32258 in gd Aug 27 16:09:43 home-spb kernel: [148572.493956] JBD2: Spotted dirty metadata buffer (dev = sdc2, blocknr = 0). There's a risk of filesystem corruption in case of system crash. One time, machine rebooted (not manually), when I turn it on, it runs fsck on /dev/sdc2 and fix some errors and some files are missing on /dev/sdc2 I'v check /dev/sdc2 for badblocks, it doesn't have it ( using e2fsck -c /dev/sdc2 ) Here is the output of fsck http://pastebin.com/D5LmLVBY What else I can do to understand what's wrong here? BTW for /dev/sdc1 no message like that, in kern.log Linux version: 3.3.0 Distributive: Debian wheezy

  Read the article

• How long does an ext4 format take?

  - by Bill O'Dwyer

  The USB cable on my Iomega Prestige 1TB hard drive conked out a while back, and I've finally managed to get a new one. I removed the old NTFS file system because I use Windows maybe once a month, and then only for Windows-only activities. So I plug in the HDD to my laptop, and get it to start converting to ext4. Gparted is currently on the "create new ext4 file system" and has been for about 2 hours. Is this right? I know 1TB is fairly large, but the last time I did this, I'm pretty sure it was a fast(er) job.Can anybody shed some light on what's going on here?

  Read the article

• How can I optimise ext4 for reliability?

  - by amin

  As ext4 was introduced as more reliable than ext3 with block journals, is there any chance to suppose it 100% reliable? What if enabling block journaling on it, which is disabled by default? As friend's guide to explain my case in more detail: I have an embedded linux device, after installation keyboard and monitor is detached and it works standalone. My duty is to make sure it has reliable file-system so with errors there is no way for manual correct faults on device. I can't force my customer to use a ups with each device to ensure no fault by power-failure. What more can ext4 offer me besides block journaling? Thanks in advance.

  Read the article

• How do I recover a .ogv on ext4?

  - by gsedej

  Hi! I have very a simple question. How to recover a .ogv file on my /home ext4 partition? I overwrote the .ogv file (I confused input and output in Arista transcoder). I did research. TestDisk can undelete files on FAT and NTFS, but not on EXT4. PhotoRec does not support .ogv recovering. Foremost also does not support .ogv More info: The file is located at: /home/gasper/Video/Webcam/2011-02-02-181200.ogv

  Read the article

• How can I optimise ext4 for reliability?

  - by amin

  As ext4 was introduced as more reliable than ext3 with block journals, is there any chance to suppose it 100% reliable? What if enabling block journaling on it, which is disabled by default? As friend's guide to explain my case in more detail: I have an embedded linux device, after installation keyboard and monitor is detached and it works standalone. My duty is to make sure it has reliable file-system so with errors there is no way for manual correct faults on device. I can't force my customer to use a ups with each device to ensure no fault by power-failure. What more can ext4 offer me besides block journaling? Thanks in advance.

  Read the article

• shrink ext4 partition

  - by user276851

  My question is similar to Move ext4 partition, but the challenge I couldn't figure out is how to shrink a partition from the start. So suppose originally the partition (with raid) is like this. (************** /dev/md127 ***************) After resizing, I want to achieve like this. (*** unallocated ***)(**** /dev/md127 ****) Note, I cannot use gparted, and parted does not support ext4. The commands I have tried so far, % resize2fs -p /dev/md127 1676G # <== This is good. % lvreduce -L 1676G /dev/md127 Path required for Logical Volume "md127" Please provide a volume group name Run `lvreduce --help' for more information. Failed here, I guess it may be because the underlying partition is primary and the lvreduce only works on logical? Anyway, no idea. Then after that, I am thinking to create another partition right after this one, copy the data to that partition, and remove this one, like. 1. (************** /dev/md127 ***************) 2. (**** /dev/md127 ****)(*** new partition **) 3. (*** unallocated ****)(**** /dev/md127 ****) Thanks for the help.

  Read the article

• How to mount ext4 partition?

  - by Flint

  How do I mount an ext4 partition as my user account so I wouldn't require root access to r/w on it? I used -o uid=flint,gid=flint on the mount command but I keep getting mount: wrong fs type, bad option, bad superblock on /dev/sda7, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so Another thing, I want avoid using udisks for now as it doesn't let me mount to my specified mount point name.

  Read the article

• Setting up quotas on 64-bit RHEL6 OS with ext4 filesystem

  - by Rob Mangiafico

  Setting up a new 64 bit RHEL 6 server with ext4 FS. Have only worked with ext3 and 32bit RHEL5 before. No matter what I try, I cannot get it to work. Current settings for mount (from "mount" command): /dev/sda7 on / type ext4 (rw,noatime) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw,noexec,nosuid) /dev/sdb1 on /backup type ext4 (rw) /dev/sda1 on /boot type ext4 (rw,noatime) /dev/sda8 on /home type ext4 (rw,noatime,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0) /dev/sda2 on /tmp type ext4 (rw,noexec,noatime) /dev/sda6 on /usr type ext4 (rw,noatime) /dev/sda5 on /var type ext4 (rw,noatime,usrjquota=aquota.user,jqfmt=vfsv0) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) Essentially trying to get user/group quotas on /home, and user quotas on /var. Created the aquota.user and aquota.group files on /home and /var: -rw-r--r-- 1 root root 0 Nov 17 13:37 /home/aquota.group -rw-r--r-- 1 root root 0 Nov 17 13:37 /home/aquota.user -rw------- 1 root root 0 Nov 17 11:43 /var/aquota.user When I run quoatcheck I get: quotacheck -vguma quotacheck: WARNING - Quotafile /home/aquota.user was probably truncated. Cannot save quota settings... quotacheck: WARNING - Quotafile /home/aquota.group was probably truncated. Cannot save quota settings... quotacheck: WARNING - Quotafile /var/aquota.user was probably truncated. Cannot save quota settings... Then I attempt quotaon and get: quotaon -av quotaon: Cannot find quota file on /home [/dev/sda8] to turn quotas on/off. quotaon: Cannot find quota file on /home [/dev/sda8] to turn quotas on/off. quotaon: Cannot find quota file on /var [/dev/sda5] to turn quotas on/off. quota rpms installed: rpm -qa|grep -i quota quota-3.17-16.el6.x86_64 quota-devel-3.17-16.el6.x86_64 Any ideas what I'm doing wrong or what I should adjust to get quotas to work as they do in ext3/32bit?

  Read the article

• how to make ext4 more reliable?

  - by amin

  hi dears as ext4 introduced more reliable than ext3 with block journals, is there any chance to suppose it 100% reliable? what if enabling block journaling on it, which is disabled by default? as friend's guide to explain my case in more detail: i have an embedded linux device, after installation keyboard and monitor is detached and it works standalone. my duty is to make sure it has reliable file-system so with errors there is no way to fsck on device. i can't force my customer to use a ups with each device to ensure no fault by power-failure. what can you offer me more than enabling block journaling? thanks in advance

  Read the article

• Is ext4 more expensive than ntfs?

  - by ???

  I have just converted an NTFS partition to ext4, however the total space seems reduced from 421G to 415G. Where did the 6G go? And, the reserved space is grown to 199M in ext4, much larger compared to 78M in NTFS, why? The partition is mainly used for movies/musics, so most files are very large (10M each). I want to use ext4 file system, is there any suggestion? mkfs.ntfs: /dev/sdb4 421G 78M 421G 1% /mnt/mmedia mkfs.ext4: /dev/sdb4 415G 199M 393G 1% /mnt/mmedia It's also weired that the remaining size of ext4 is 393G, shouldn't it be 415G or 414G? What happened to the disappeared 22G? Compared to NTFS, ext4 seems eaten 28G in total.

  Read the article

• What is the best freeware app for Windows to mount EXT4 partitions (from a GPT 4TB Disk) as RW, safely without corrupting the EXT4 partition?

  - by Bran

  My Computer is set up as Dualboot Windows and Ubuntu. I have 1 OS drive, and 1 hard drive with a /backup partition (which has all my family photos and data) and it is ext4. Also note... it is EXT4, and it is GPT, and it is 4TB size. Anyway, Windows can not mount the /backup ext4 partition. What software/freeware do you reccomend for Windows? Preferrably looking for someone with experiance using it for a long time and not have problems with EXT4 partition which is a 4TB, GPT Disk. Thank you for your advice and guidance! Always, appreciate everyones help at askubuntu, you guys are the best. Any ideas?

  Read the article

• What's wrong with my ext4 partition?

  - by bumbling fool

  What is wrong with this picture? Top is output from "df -h", bottom is gparted. I suspect I'm missing a lot of free space. No problems other than that (yet). Can somebody suggest the best (non-destructive) way to correct this? sudo dumpe2fs -h /dev/sda3: (source http://pastebin.com/nAvrdT4E) Filesystem volume name: <none> Last mounted on: / Filesystem UUID: 9f6eff64-60d7-4eec-81d5-1e8acd818b38 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) 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 Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 1602496 Block count: 6406144 Reserved block count: 320306 Free blocks: 4842284 Free inodes: 1361222 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1022 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8176 Inode blocks per group: 511 RAID stride: 32692 Flex block group size: 16 Filesystem created: Sun Nov 8 18:18:13 2009 Last mount time: Tue Mar 1 01:04:27 2011 Last write time: Mon Feb 28 04:27:34 2011 Mount count: 16 Maximum mount count: 28 Last checked: Thu Feb 24 06:23:39 2011 Check interval: 15552000 (6 months) Next check after: Tue Aug 23 07:23:39 2011 Lifetime writes: 227 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 First orphan inode: 268015 Default directory hash: half_md4 Directory Hash Seed: cc101517-e617-482b-a883-a72919419c84 Journal backup: inode blocks Journal features: journal_incompat_revoke Journal size: 128M Journal length: 32768 Journal sequence: 0x001d3000 Journal start: 7787 fdisk and parted output per requests: http://pastebin.com/EGVH7Ken

  Read the article

• ext4 filesystem corruption -- maybe hardware error?

  - by pts

  I'm getting these errors in dmesg after about half an hour after I turn on the computer: [ 1355.677957] EXT4-fs error (device sda2): htree_dirblock_to_tree: inode #1318420: (comm updatedb.mlocat) bad entry in directory: directory entry across blocks - block=5251700offset=0(0), inode=1802725748, rec_len=179136, name_len=32 [ 1355.677973] Aborting journal on device sda2-8. [ 1355.678101] EXT4-fs (sda2): Remounting filesystem read-only [ 1355.690144] EXT4-fs error (device sda2): htree_dirblock_to_tree: inode #1318416: (comm updatedb.mlocat) bad entry in directory: directory entry across blocks - block=5251699offset=0(0), inode=2194783952, rec_len=53280, name_len=152 [ 1356.864720] EXT4-fs error (device sda2): htree_dirblock_to_tree: inode #1312795: (comm updatedb.mlocat) bad entry in directory: directory entry across blocks - block=5251176offset=1460(13748), inode=1432317541, rec_len=208208, name_len=119 /dev/sda is an SSD, and it's using the noop scheduler. /etc/fstab entry: UUID=acb4eefa-48ff-4ee1-bb5f-2dccce7d011f / ext4 errors=remount-ro,noatime,discard,user_xattr 0 1 System information: $ cat /proc/mounts | grep /dev/sd /dev/sda1 /boot ext2 rw,noatime,errors=continue 0 0 $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=10.04 DISTRIB_CODENAME=lucid DISTRIB_DESCRIPTION="Ubuntu 10.04.3 LTS" $ uname -a Linux leetpad 2.6.35-30-generic-pae #61~lucid1-Ubuntu SMP Thu Oct 13 21:14:29 UTC 2011 i686 GNU/Linux I've run memtest for 7 hours, it didn't found any memory errors. Any obvious ideas what can go wrong in this case? The most reasonable thing I can imagine is that the SSD is silently dropping some write requests, which eventually leads to an EXT4 filesystem inconsistency (but no disk I/O errors). How can this happen? Is there a relevant configuration option I should ensure to be set correctly? What tools should I use to diagnose the hardware failures? Would it be possible to diagnose the SSD failure without overwriting data?

  Read the article

• mounting ext4 fs with block size of 65536

  - by seaquest

  I am doing some benchmarking on EXT4 performance on Compact Flash media. I have created an ext4 fs with block size of 65536. however I can not mount it on ubuntu-10.10-netbook-i386. (it is already mounting ext4 fs with 4096 bytes of block sizes) According to my readings on ext4 it should allow such big block sized fs. I want to hear your comments. root@ubuntu:~# mkfs.ext4 -b 65536 /dev/sda3 Warning: blocksize 65536 not usable on most systems. mke2fs 1.41.12 (17-May-2010) mkfs.ext4: 65536-byte blocks too big for system (max 4096) Proceed anyway? (y,n) y Warning: 65536-byte blocks too big for system (max 4096), forced to continue Filesystem label= OS type: Linux Block size=65536 (log=6) Fragment size=65536 (log=6) Stride=0 blocks, Stripe width=0 blocks 19968 inodes, 19830 blocks 991 blocks (5.00%) reserved for the super user First data block=0 1 block group 65528 blocks per group, 65528 fragments per group 19968 inodes per group Writing inode tables: done Creating journal (1024 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 37 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. root@ubuntu:~# tune2fs -l /dev/sda3 tune2fs 1.41.12 (17-May-2010) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: 4cf3f507-e7b4-463c-be11-5b408097099b Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 19968 Block count: 19830 Reserved block count: 991 Free blocks: 18720 Free inodes: 19957 First block: 0 Block size: 65536 Fragment size: 65536 Blocks per group: 65528 Fragments per group: 65528 Inodes per group: 19968 Inode blocks per group: 78 Flex block group size: 16 Filesystem created: Sat Feb 5 14:39:55 2011 Last mount time: n/a Last write time: Sat Feb 5 14:40:02 2011 Mount count: 0 Maximum mount count: 37 Last checked: Sat Feb 5 14:39:55 2011 Check interval: 15552000 (6 months) Next check after: Thu Aug 4 14:39:55 2011 Lifetime writes: 70 MB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: afb5b570-9d47-4786-bad2-4aacb3b73516 Journal backup: inode blocks root@ubuntu:~# mount -t ext4 /dev/sda3 /mnt/ mount: wrong fs type, bad option, bad superblock on /dev/sda3, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so

  Read the article

• Testdisk won’t list files for an ext4 partition inside a LVM inside a LUKS partition

  - by user1598585

  I have accidentally deleted a file that I want to recover. The partition is an ext4 partition inside an LVM partition that is encrypted with dm-crypt/LUKS. The encrypted LUKS partition is: /dev/sda2 which contains a physical volume, with a single volume group, mapped to: /dev/mapper/system And the logical volume, the ext4 partition is mapped to: /dev/mapper/system-home A # testdisk /dev/mapper/system-home will notice it as an ext4 partition but tells me that the partition seems damaged when I try to list the files. If I # testdisk /dev/mapper/system it will detect all the partitions, but the same happens if I try to list their files. Am I doing something wrong or is it a known bug? I have searched but haven’t found any clue.

  Read the article

• 12.04 ext4 - cannot create regular file/No space left - with a lot of space and inodes

  - by user1434058

  This seems similar: EXT4 "No space left on device (28)" incorrect but there is no explanation I created an ext4 filesystem on a RAID 1 array with: mke2fs -t ext4 -T small /dev/md0 Copying a single directory with many tiny files I get: cp: cannot create regular file `/mnt/raid1_new/pics/pic3412.jpg': No space left on device space used 5% inodes used 1% I manually tried: cp /source/test1.jpg /mnt/raid1_new/pics/test1.jpg --- error cp /source/test1.jpg /mnt/raid1_new/pics/test2.jpg --- ERROR cp /source/test1.jpg /mnt/raid1_new/pics/test3.jpg --- no error Notes: RAID 1 disks are error free. I tried mv instead of cp and got the same thing. I tried omitting -T small with no effect Can somebody help me understand this magic?

  Read the article

• ext4: error loading journal

  - by cloudyOutside

  I have an external hard drive with two partitions: A small FAT32 which is mostly empty and works fine and a large ext4 with tons of data, most of which isn't backed up. The ext4 is visible, but can't be mounted. I get an "error loading journal" error. The drive is a Western Digital Caviar Blue 500GB. Roughly 30GB of that is FAT32 and the rest is the ext4. The light on the enclosure turns red when reading from the bad partition. It was made by Cavalry. There wasn't any warning, but coincidentally, I've been thinking lately that I should get two large capacity drives for real backups. Is there anything that can be done? I'm not even sure I have enough storage to backup everything even if it is redeemable.

  Read the article

• EXT4-fs error (device loop0) ext4_mb_generate_buddy

  - by Rachel Nark

  I've been randomly getting theses in my /var/log/messages [5747511.945300] EXT4-fs error (device loop0): ext4_mb_generate_buddy: EXT4-fs: group 1: 29505 blocks in bitmap, 29455 in gd Not had any luck with google is this a drive failue or just a kernel glitch or a need to fsck? kernel: 2.6.32-320.4.1.lve1.1.4.el6.x86_64 #1 SMP Wed Mar 7 06:32:27 EST 2012 x86_64 x86_64 x86_64 GNU/Linux the DC i think gave me a new drive over a few months ago

  Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >