[mythtv-users] LVM Issue with zero-length files

[Larry K]

Shawn,

You were right on the money.

Somehow, my ivtv driver must have gotten messed up when I installed the new
xfs volume. I can't figure that one out, tho. I was so focused on the
xfs/LVM issue, it never occurred to me that the ivtv drivers got hosed. Good
call.

I ran a few more tests and found that I could create new files with vi, and
cat /dev/video did not work no matter where I directed the output.

Anyhow, after I reinstalled ivtv, the problem went away.

Thanks for the help. Your questions made me think outside the box I was
stuck in :)

On 9/28/05, Shawn Asmussen <shawn.asmussen at gmail.com> wrote:
>
>
>
> On 9/28/05, Larry K <lunchtimelarry at gmail.com> wrote:
> >
> > Calling all LVM experts!!
> >
> > Up until recently, I had been running LVM with only a single physical
> > volume. I probably have 100GB of data files in the volume, waiting to be
> > watched. So, Myth was running fine and all was well, except I had a 150GB
> > partition just laying around, not in use. So, I decided to extend my volume
> > group and add this 150GB to it, like so:
> >
> >    1. Using fdisk, deleted /dev/hda4 partition
> >    2. Using fdisk, created /dev/hda4 as LVM
> >    3. Created physical volume: pvcreate /dev/hda4
> >    4. Extended volume group: vgextend vg /dev/hda4
> >    5. Ran vgdisplay to see amount of free space that needs to be
> >    extended (18214)
> >    6. unmount the volume group: umount /dev/vg/video
> >    7. extend: lvextend -l +18214 /dev/vg/video
> >    8. mount /dev/vg/video
> >    9. grow the xfs file system: xfs_grow /dev/vg/video
> >    10. Remove /video from /etc/fstab
> >
> > Now, df -k shows the new space:
> >
> > [root at mythtv ~]# df -k
> > Filesystem 1K-blocks Used Available Use% Mounted on
> > /dev/hda2 10080520 2938120 6630332 31% /
> > /dev/hda1 101086 16752 79115 18% /boot
> > none 257908 0 257908 0% /dev/shm
> > /dev/mapper/vg-video 442105856 113816336 328289520 26% /video2
> >
> > Everything appeared to be OK. I now had a 450GB partition for myth,
> > instead of 300GB. However, I soon discovered that new files are written with
> > a length of zero (empty files). Doh! The mythfrontend was able to play back
> > the existing files that were in the VG, but if I tried to delete a file, the
> > frontend would hang. That's when I knew I had a problem for sure.
> >
> > Also odd is that when, as root, I cat /dev/video0 > /video2/xxx.mpg,
> > this file is also empty. However, if I copy an existing file, as in
> >
> > cp /video2/blah blah.nuv /video2/xxx, it shows up with the proper
> > length. So old files copy correctly, but new files are not written
> > correctly.
>
>  The fact that you can write files this way, tends to suggest that it
> might not be a problem with your xfs filesystem. Could your ivtv drivers (Or
> whatever you're using) have gotten confused during this procedure somehow,
> and stopped producing output? I would try to do a cat /dev/video test, but
> write the test file somewhere else that isn't on your expanded filesystem.
> If you get a zero length file there, I would suggest rebooting your box, and
> making sure that your capture drivers are working. If they got hosed up
> somehow, it could explain both why your cat /dev/video0 test, and why new
> files created created by mythtv were zero length. BTW, I didn't notice it in
> your list of steps, so did you shutdown mythbackend during this procedure?
> You say that you can copy existing files, but not write new ones, but you
> didn't mention trying to write new files by any other method than the cat
> /dev/video0 method. Did you try anything else, like creating a new file with
> vi, or something like that? If that works, and your cat /dev/video0 doesn't
> work, I'd almost certainly say that something is going on with the video
> capturing itself, not your xfs filesystem.
>
> WTF?
> >
> > There are no error messages in either the myth logs, nor the log file at
> > /var/log/messages.
> >
> > I did notice that one of the HDs is running DMA 100, while the other is
> > DMA 133. Does this matter to LVM?
>
>  Shouldn't make any difference.
>
> Anyone have any thoughts as to what might be causing this? I am totally
> > stumped. If there is a way to back out and shrink the VG back to 300GB to
> > fix this, I'm all ears!
> >
> >
> > _______________________________________________
> > mythtv-users mailing list
> > mythtv-users at mythtv.org
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20051002/59a69300/attachment.htm